Not only was it discussed, it was tried, maybe in the run-up to Go 1. It was a while ago, anyway.
But we found it made code harder to understand and brittle when you have lots of fields, so the change was not rolled out. As is often the case, what looks good for simple examples breaks down in the real world. It was a judgement call, but one that seemed right at the time and may be revisited. For a more recent related discussion see https://github.com/golang/go/issues/12854. -rob On Thu, Dec 22, 2016 at 3:48 AM, Steve Roth <[email protected]> wrote: > The survey that was recently posted here asked, among other things, what > changes to the language would be most useful. The one that immediately > came to my mind was getting rid of the need for redundant type specifiers > (examples below). It occurred to me that this must have been discussed > before I joined the Go scene, probably multiple times — but apparently I > haven't hit on the right search keywords to find it (sorry about that). So > my question is, why does the language require these redundant type > specifiers? Is there a need for them that I'm just missing? > > Example 1: > > type S struct { > A []int > B []string > } > var RequiredToday = S{ > []int{1, 2}, > []string{"a", "b"}, > } > var WithoutRedundancy = S{ > {1, 2}, > {"a", "b"}, > } > > > > The compiler has all of the necessary information, from the struct type > definition, to interpret WithoutRedundancy. Why is that not allowed? > > Example 2: > > type FuncType func(a string, b int, c float64) (string, error) > > func RequiredToday(a string, b int, c float64) (string, error) { > ... > } // and no way to explicitly see that it's supposed to be a FuncType > > func WithoutRedundancy FuncType { > ... > } > > > > Admittedly this is a bit more of a stretch, but again, the compiler has > all of the necessary information from the type definition (which, you'll > note, included names for the parameters). Writing switch tables, HTTP > handlers, etc., would be a lot more convenient without having to repeat all > of the boilerplate. Is there a reason the language doesn't permit this? > > If there isn't a strong reason for these required redundancies, permit me > to advocate removing them. As far as I can tell, doing so would not > introduce any incompatibilities. > > Regards, > Steve > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
