Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
spec: un-conflate variables and values #20181
The notions of variable and value, although meaningfully distinct, are often conflated in the spec. Some examples:
This is probably all of them, but I'm not sure.
Found one more: the definition of pointer equality says that things point to the same variable, but as currently defined, slice elements count as variable. Thus, arguably,
It's of note that formally defining this to always be true provides a defined way to compare slices of non-zero-size element type.
Agreed this is an issue: dynamic type should be a property of interface values, not interface variables.
Not sure I follow the issue. Is the problem that we say "Structured variables of array, slice, and struct types have elements" when zero-length arrays and empty structs do not?
I believe this is correct. Values are not addressable, but when they're stored in memory (which is always termed a "variable") they are.
Agreed this seems to be worth clarifying (unless I'm overlooking something). We define that the dynamic type must be a "concrete" type, which I believe is intended to mean a non-interface type, but we don't actually define that.
I at least think "A variable of interface type can store a value of any type with a method set that is any superset of the interface." needs to be clarified to something like "A value of interface type can store a value of any concrete type with ...".
I believe it's meant to explain that
means the same as:
See 2d9378c for the ambiguities this wording was introduced to address.
Slice types are defined to reference the storage of an underlying array:
And slice expressions are defined to access these:
No, the issue is that this definition says that elements of arrays are treated like variables. But this is not true of unaddressable arrays. The same goes for elements of unaddressable structs.
The spec defines an addressable value as "either a variable, pointer indirection, or slice indexing operation; or a field selector of an addressable struct operand; or an array indexing operation of an addressable array." and refers to this on several occasions. I think this is a much better approach then trying to refer to them as variables, because it is more comprehensive. The "act like variables" language when discussing structured variables is unclear whether that is normative text saying "they count as variables for the purposes of the spec" or merely informative implying "they are addressable and thus can be used in many of the same contexts as variables". A cleaner way to write this, perhaps, is to say that an addressable value has an address, and then say that two addressable values have the same address if (not counting zero-size objects):
If an operand is the address of a pointer indirection operation, then its address is the address stored in the pointer. If an operand is a slice index operation, its address is the address of the corresponding element of the underlying array.
Ah, thanks. Sounds good.
I agree in all but the definition of the space. The issue with spec as written is that defines pointer equality as being equality of variables:
The spec also says, in the text I quoted earlier about structured types, that slice elements and array elements are variables. It is unclear at best about whether or not the identity of
However, the way this works is, in my opinion, needlessly complicated by the lack of an explicit statement.
Okay, that's intentional though and the convention chosen for the Go spec: "variable" is the term used to refer to any memory storage location where a value can be stored and that can be addressed. Variables can contain other variables. Some variables are explicitly declared with
The elements of array and struct values (as opposed to variables) are not addressable, so they're not variables.
I see. Perhaps we should rephrase that to "addressable expression". In all cases, the expression identifies a variable / memory location.