[go-nuts] Re: [generics] Zero value

[Ivan Ivanyuk]

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  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 
> ,
>  
> 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 
>  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 , 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/df88fcc6-3422-4260-bcc7-b499f6c912ddo%40googlegroups.com.

[go-nuts] Re: [generics] Zero value

[Max]

Types are not first-class in Go, thus T.someMethod() is somewhat an unusual 
syntax.

The proposal  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  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 
>> ,
>>  
>> 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 
>>  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 , 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/ab0248d6-c292-4e22-a1bd-b5d0b0df6aeeo%40googlegroups.com.

[go-nuts] Re: [generics] Zero value

[Andrew Werner]

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  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  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 
>>> ,
>>>  
>>> 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 
>>>  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 , 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.

[go-nuts] Re: [generics] Zero value

[brunokim . mc]

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  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  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 
 ,
  
 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 
  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 , 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/99d8692e-9db3-4009-853b-d6a33064724ao%40googlegroups.com.

[go-nuts] Re: generics: Zero value for any type parameter

[Johan Bolmsjö]

torsdag 16 december 2021 kl. 23:40:09 UTC+1 skrev Johan Bolmsjö:

>
> My workaround has been to create a dummy variable, zeroValue in the 
> following example. I'm wondering if this is how to solve this problem or if 
> there is a better way.
>
>
I  realized I should have read the generics proposal before asking this 
question. My current workaround is mentioned together with some possible 
future improvements. At the time it seems to be idiomatic code. Sorry for 
the noise.
 

-- 
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/eebade7f-7168-458f-adcc-8cc4875a652en%40googlegroups.com.