proposal: spec: permit eliding the type of struct fields in nested 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. When the type of a nested composite literal may derived from its context, that type may be elided in all cases except when the composite literal is the value of a struct field. ```go type T struct{ V int } var _ = map[T]T{{1}: {1}} // type elided from map key and element var _ = []T{{1}} // type elided from slice element var _ = [...]T{{1}} // type elided from array element var _ = struct{ F T }{F: T{1}} // type is required ``` I propose that elision be permitted in this case as well. ```go var _ = struct{ F T }{F: {1}} var _ = struct{ F *T }{F: {1}} ``` I submit that the arguments in favor are the same as for eliding the type in other contexts, as well as conceptually simplifying the language--it is simpler to say that types may always be elided in nested literals (when the type can be derived from context) than to say that types may be elided in all but one case. Proposed spec change: > Within a composite literal of array, slice, **struct,** or map type T, ... This proposal is a subset of #12854, which proposes elision of types in all composite literals, not just nested ones.
Posted by neild on Aug 17, 2017, 5:53 PM
Tags
Related issues
- struct's lifetime requirements can be bypassed via covariant field assignment
- Proposal to Reorganize the Moderation Team and Review Moderation Policies
- Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
- proposal: container/...: generic collection types
- Better Custom Endpoint BYOK
- A concrete policy for backward compatibility until Godot 5.0
Raise real-world problems, find people facing the same issue, and discuss solutions.4,500 issues0 comments
github (Other)
struct's lifetime requirements can be bypassed via covariant field assignment
Proposal to Reorganize the Moderation Team and Review Moderation Policies
Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
proposal: container/...: generic collection types
Better Custom Endpoint BYOK
A concrete policy for backward compatibility until Godot 5.0
New MTP models not supported
Tracking: 429 / Capacity Issues
proposal: spec: permit eliding the type of struct fields in nested 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. When the type of a nested composite literal may derived from its context, that type may be elided in all cases except when the composite literal is the value of a struct field. ```go type T struct{ V int } var _ = map[T]T{{1}: {1}} // type elided from map key and element var _ = []T{{1}} // type elided from slice element var _ = [...]T{{1}} // type elided from array element var _ = struct{ F T }{F: T{1}} // type is required ``` I propose that elision be permitted in this case as well. ```go var _ = struct{ F T }{F: {1}} var _ = struct{ F *T }{F: {1}} ``` I submit that the arguments in favor are the same as for eliding the type in other contexts, as well as conceptually simplifying the language--it is simpler to say that types may always be elided in nested literals (when the type can be derived from context) than to say that types may be elided in all but one case. Proposed spec change: > Within a composite literal of array, slice, **struct,** or map type T, ... This proposal is a subset of #12854, which proposes elision of types in all composite literals, not just nested ones.
Comments (0)
No comments yet. Start the discussion.