Types are not first-class in Go, thus T.someMethod() is somewhat an unusual syntax.
The proposal <https://github.com/golang/go/issues/12854> to use 'T{}' to mean zero value of T breaks Go compatibility promise: if T is a map type or a slice type, 'T{}' already has a meaning: create a non-nil, zero-elements map (or slice). Instead the zero value of such types is nil. Using '_' could be an elegant solution in places where type inference can deduce the correct type. Two more ideas that I did not see yet are: 1. use 'T()' to mean zero value of T - currently does not compile, thus Go compatibility promise is preserved. 2. define a new compiler builtin 'zero(T)' On Friday, June 19, 2020 at 1:59:59 PM UTC+2, Ivan Ivanyuk wrote: > > What about something like int.CreateZeroValue(), or T.CreateZeroValue() > and CreateZeroValueInterface? > > On Thursday, June 18, 2020 at 7:34:55 PM UTC+3, [email protected] wrote: >> >> First, congratulations on the working compiler! Very cool to try out >> generics in Go. >> >> I was experimenting <https://go2goplay.golang.org/p/TCJGEprQ13K> with >> some simple generic functions and felt the need for the zero value of a >> generic type. I've read the discussion anticipated in your proposal >> <https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#the-zero-value>, >> >> so I'd like to use this topic just to provide my sentiment, and perhaps >> gather it from others. >> >> In my opinion, the most Go-like proposal >> <https://github.com/golang/go/issues/19642> is using '_' to signify the >> zero value in RHS. We are already used to having '_' in LHS to accept >> whatever type, and although the meaning is slightly changed (from >> 'whatever' to 'zero'), it's conceptually close. >> >> I'm opposed to a change that uses '{}' or 'T{}' to mean zero type, as in >> this proposal <https://github.com/golang/go/issues/12854>, because in my >> mind curly braces are used for composite types. Imagining that 'T' is a >> placeholder, It's weird replacing 'T{}' for 'int{}', for example. I'm super >> in favor of having a leaner syntax for composite types, though 😁. >> >> Whatever is decided, please don't punt on this issue and recommend >> '*new(T)'. That's really ugly and feels wrong to allocate and immediately >> dereference the value just to circumvent a syntax change. Even if the >> compiler is smart enough not to allocate anything, that's what's written in >> the source code. >> >> Thanks. >> > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ab0248d6-c292-4e22-a1bd-b5d0b0df6aeeo%40googlegroups.com.
