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.
