spec: type inferred composite literals

Composite literals construct values for structs, arrays, slices, and maps. They consist of a type followed by a brace-bound list of elements. e.g., ``` go x := []string{"a", "b", "c"} ``` I propose adding untyped composite literals, which omit the type. Untyped composite literals are assignable to any composite type. They do not have a default type, and it is an error to use one as the right-hand-side of an assignment where the left-hand-side does not have an explicit type specified. ``` go var x []string = {"a", "b", "c"} var m map[string]int = {"a": 1} type T struct { V int } var s []*T = {{0}, {1}, {2}} a := {1, 2, 3} // error: left-hand-type has no type specified ``` Go already allows the elision of the type of a composite literal under certain circumstances. This proposal extends that permission to all occasions when the literal type can be derived. This proposal allows more concise code. Succinctness is a double-edged sword; it may increase or decrease clarity. I believe that the benefits in well-written code outweigh the harm in poorly-written code. We cannot prevent poor programmers from producing unclear code, and should not hamper good programmers in an attempt to do so. This proposal may slightly simplify the language by removing the rules on when composite literal types may be elided. ## Examples Functions with large parameter lists are frequently written to take a single struct parameter instead. Untyped composite literals allow this pattern without in

Posted by neild on Oct 6, 2015, 9:26 PM

Tags

• github (Other)

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