Yes, they work, though a simpler solution is using 'var zero T' before the
return statement. It'd be nice to have it inline, specially for multiple
return values.
Em segunda-feira, 22 de junho de 2020 10:13:43 UTC-3, Andrew Werner
escreveu:
>
> 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, [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/99d8692e-9db3-4009-853b-d6a33064724ao%40googlegroups.com.
