New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
spec: clarify type elision rules for composite literals #17954
Comments
The two compilers agreeing suggests that this should (continue to) be accepted. Is there a test for this behavior that led to the compilers agreeing? If so, that would even more strongly push in that direction. If past behavior does not determine the answer, then looking at the spec itself, there are many places in the spec that talk about 'a type T' meaning "your type here" and not meaning only named types. Otherwise there is no way to talk about "any type". The text quoted seems to be talking about arbitrary types, not only named types (it never mentions names), in which case the answer is that yes the example is OK. That is, if you think of the example as being a shortening of:
(I changed the type name to avoid 'T'), then "elements ... that are addresses of composite literals may elide the &T when the element ... type is *T" seems to be satisfied. The element type X is *T for T = struct{s string}. |
CL https://golang.org/cl/33358 mentions this issue. |
I would like to agree with this (and I already have an easy fix for this for go/types: https://go-review.googlesource.com/33358). But it's not that simple. Given
this is valid
Note that If we allow the same rule for
What should the type marked with More to the point (no pun intended), we can't actually write down the element type of The spec says very clearly: "Within a composite literal of array, slice, or map type T, elements or map keys that are themselves composite literals may elide the respective literal type if it is identical to the element or key type of T." In this example, the element types are not identical. Thus, I argue that gc and gccgo are incorrect. (We may not be able to change this at this point, but then the spec has to be adjusted.) |
But the sentence you are quoting is not the relevant one. Here T is a meta-syntactic variable, and clearly the second clause does not apply--the type of the elements is not, and can not be, type |
@ianlancetaylor Fair point, I quoted the wrong sentence. The element type is I still think we're a bit on shaky ground here, but we probably should just update the spec. |
…ls with elided types Match behavior of gc and gccgo. For #17954. Change-Id: I3f065e56d0a623bd7642c1438d0cab94d23fa2ae Reviewed-on: https://go-review.googlesource.com/33358 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL https://golang.org/cl/33361 mentions this issue. |
Per the spec ( https://golang.org/ref/spec#Composite_literals ):
"Within a composite literal of array, slice, or map type T, elements or map keys that are themselves composite literals may elide the respective literal type if it is identical to the element or key type of T. Similarly, elements or keys that are addresses of composite literals may elide the &T when the element or key type is *T."
Given this paragraph, it's not obviously clear if the following code should be permitted:
Here, the element type is a named type T that happens to be a *S. From the phrasing in the spec, it's not obvious whether the rule also applies in this case, or not (it doesn't explicitly say whether the underlying type is meant or not).
The gc and gccgo compilers accept the code above, go/types does not.
In contrast, the code below is also accepted by go/types (and clearly satisfies the spec rule).
The text was updated successfully, but these errors were encountered: