Home  >  Article  >  Backend Development  >  Dynamic type not cleared when reassigning variable - is this a bug?

Dynamic type not cleared when reassigning variable - is this a bug?

PHPz
PHPzforward
2024-02-13 16:00:11446browse

重新分配变量时动态类型未清除 - 这是一个错误吗?

php editor Xiaoxin is here to answer a common question: "Dynamic types are not cleared when reassigning variables - is this a bug?" In PHP, the variable Dynamic typing is an important feature of its flexibility. When we reassign a different type of value to a variable, PHP will automatically adjust the variable type according to the new value. However, sometimes we may forget to clear variables and get unexpected results. So, does this situation count as a mistake? Let’s explore it together.

Question content

There is a well-known quirk in Go that interfaces holding nil values ​​are not equal to nil. This is because under the hood, an interface is a combination of a dynamic type and a value, which is nil only if both are nil. So (*MyStruct)(nil) != nil but (nil)(nil) == nil. This blog explains it better.

I found something related to this behavior that surprised me, here: https://goplay.tools/snippet/VF8oWt9XvO8. The code is also copied below.

It seems that if you reassign a variable assigned a dynamic type, the dynamic type is remembered and retained as the new value. This seems unexpected to me, I thought reassigning the variable should overwrite all past state.

I checked the language specification but it's a bit vague: https://go.dev/ref/spec#Assignability

<code>
Unlike regular variable declarations, a short variable declaration may redeclare variables provided they were originally declared earlier in the same block ... Redeclaration does not introduce a new variable; it just assigns a new value to the original.
</code>

Unclear if this means just the value, or the value plus dynamic type.

Is this behavior intentional in the language, or is it some side effect of the runtime reusing memory for variable reallocation without clearing all state?

Code:

package main

import (
    "fmt"
)

type CustomError struct{}

func (e *CustomError) Error() string {
    return "err"
}

// ===================

func FuncThatReturnsCustomError() *CustomError {
    return nil
}

func FuncThatReturnsCustomErrorAsErrorInterface() error {
    // although the underlying returned value is nil, the return value from this func != nil
    // https://glucn.medium.com/golang-an-interface-holding-a-nil-value-is-not-nil-bb151f472cc7
    return FuncThatReturnsCustomError()
}

// ===================

func main() {
    // Assign a non-nil value to err (value is nil, dynamic type is not)
    err := FuncThatReturnsCustomErrorAsErrorInterface()
    fmt.Printf("err == nil: %v                                    false because although the value is nil, the dynamic type is not nil (expected)\n", err == nil)

    // Call func where return type is a pointer to a struct and and returns nil
    // It is nil, as expected, this call is just to provide a comparison with the call after
    newlyDeclaredErr := FuncThatReturnsCustomError()
    fmt.Printf("newlyDeclaredErr == nil: %v                        true because func returned nil (expected)\n", newlyDeclaredErr == nil)

    // Exactly the same call as above, but reusing the original err variable instead of declaring a new one
    // Back to not nil, unexpected
    err = FuncThatReturnsCustomError()
    fmt.Printf("original err reassigned == nil: %v                false presumably because err remembered its old dynamic type even after reassignment (unexpected)\n", err == nil)

    // Reassign err again, but explicitly to nil rather than by calling a function that returns nil. This time it's nil again
    err = nil
    fmt.Printf("original err after assignment to nil == nil: %v    true, expected but not consistent with the case above\n", err == nil)
}

Solution

Your "unexpected" part is this:

err = FuncThatReturnsCustomError()

You expect the result to be nil. err is a variable of interface type (error), and the return type of FuncThatReturnsCustomError() is *CustomError. This is not an interface type, but a concrete type (pointer to CustomError). Since it returns a non-interface value, it must be wrapped into an interface value when assigned to a variable of interface type. This is where non-nil interface values ​​will be created. This has nothing to do with "remembering" or "preserving" old type information.

If you use a function with the following interface result type:

func returnNilErr() error {
    return nil
}

and test it:

err = returnNilErr()
fmt.Printf("result of returnNilErr() == nil: %v\n", err == nil)

What you get (try it on Go Playground):

result of returnNilErr() == nil: true

Because returnNilErr() already has an interface result type (error), so its return value does not need to be packaged into an interface value and assigned to err Variables can be used as is. p>

See related/possible duplicates: Hide nil values ​​to understand why Go fails here

Go FAQ: Why is my nil error value not equal to nil? 一个>

The above is the detailed content of Dynamic type not cleared when reassigning variable - is this a bug?. For more information, please follow other related articles on the PHP Chinese website!

Statement:
This article is reproduced at:stackoverflow.com. If there is any infringement, please contact admin@php.cn delete