In order to get a zero value, does the following work today? Is it
acceptable?
func GenericFunc(type T)() T {
return func() (t T) { return t }()
}
This could also just be written like below but above I was trying to
demonstrate how to make a zero value within another function.
func ZeroValue(type T)() (t T) {
return t
}
On Monday, June 22, 2020 at 8:09:11 AM UTC-4, Max wrote:
>
> 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, bruno...@gmail.com 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/b84a3ece-b44e-46b3-832c-485b4cf1427co%40googlegroups.com.
