Re: [go-nuts] allow {3}, {true} etc

[roger peppe]

On 24 October 2016 at 21:14, Nate Finch  wrote:
> Because it's consistent with how you get a pointer for other types... if I'm
> used to using {x} for structs, maps, and slices, then it's perfectly
> natural to try that with builtins and arrays.  If someone says "oh, sorry,
> for ints you have to use ref(5)" then I'm going to get annoyed at an
> inconsistency that seems to exist for no reason.
>
> It's also less likely to overlap with existing code.  A function called ref
> could very well already exist in a current codebase.  But there's likely
> almost no code that uses builtin type names as anything other than the types
> themselves.  And unless you have structs that use builtin type names,
> {5} won't currently compile.

It doesn't really matter if a function called ref is defined already,
as it won't be a problem until you actually want to use it.
(FWIW there are no functions named "ref" in the 1640556
lines of Go code in my GOPATH).

To me the T{...} syntax says "structured type literal" - wrapping
an integer in {} and saying that it's a scalar value seems wrong.

I like "ref" because it involves almost no changes to existing
tooling and it's also useful in other case.

For example, I commonly want to make a shallow copy
of an object. Currently I tend to do this:

func x(t *T) {
t1 := *t
y()
}

but feels a little awkward that t1 is of a different type than T.

func x(t *T) {
t1 := ref(*t)
y(t1)
}

feels a little cleaner.

  cheers,
rog.


>
> On Monday, October 24, 2016 at 3:45:29 PM UTC-4, rog wrote:
>>
>> How would new syntax be better than a built-in function with exactly the
>> semantics you are after and shorter to type to boot?
>>
>>
>> On 23 Oct 2016 01:50, "Nate Finch"  wrote:
>>>
>>> I'd much rather have syntax that just works rather than another built-in
>>> function.
>>>
>>>
>>> On Sat, Oct 22, 2016, 6:17 PM roger peppe  wrote:

 I don't think I'd object if we added a new builtin function called "ref"
 with the above semantics. It worked pretty well in Limbo as an operator.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Henrik Johansson]

I agree with Nate. The consistency in typing is a very compelling argument.

On Mon, Oct 24, 2016, 22:14 Nate Finch  wrote:

> Because it's consistent with how you get a pointer for other types... if
> I'm used to using {x} for structs, maps, and slices, then it's perfectly
> natural to try that with builtins and arrays.  If someone says "oh, sorry,
> for ints you have to use ref(5)" then I'm going to get annoyed at an
> inconsistency that seems to exist for no reason.
>
> It's also less likely to overlap with existing code.  A function called
> ref could very well already exist in a current codebase.  But there's
> likely almost no code that uses builtin type names as anything other than
> the types themselves.  And unless you have structs that use builtin type
> names, {5} won't currently compile.
>
> On Monday, October 24, 2016 at 3:45:29 PM UTC-4, rog wrote:
>
> How would new syntax be better than a built-in function with exactly the
> semantics you are after and shorter to type to boot?
>
> On 23 Oct 2016 01:50, "Nate Finch"  wrote:
>
> I'd much rather have syntax that just works rather than another built-in
> function.
>
> On Sat, Oct 22, 2016, 6:17 PM roger peppe  wrote:
>
> I don't think I'd object if we added a new builtin function called "ref"
> with the above semantics. It worked pretty well in Limbo as an operator.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Nate Finch]

Because it's consistent with how you get a pointer for other types... if 
I'm used to using {x} for structs, maps, and slices, then it's perfectly 
natural to try that with builtins and arrays.  If someone says "oh, sorry, 
for ints you have to use ref(5)" then I'm going to get annoyed at an 
inconsistency that seems to exist for no reason.

It's also less likely to overlap with existing code.  A function called ref 
could very well already exist in a current codebase.  But there's likely 
almost no code that uses builtin type names as anything other than the 
types themselves.  And unless you have structs that use builtin type names, 
{5} won't currently compile.

On Monday, October 24, 2016 at 3:45:29 PM UTC-4, rog wrote:
>
> How would new syntax be better than a built-in function with exactly the 
> semantics you are after and shorter to type to boot?
>
> On 23 Oct 2016 01:50, "Nate Finch"  
> wrote:
>
>> I'd much rather have syntax that just works rather than another built-in 
>> function.
>>
>> On Sat, Oct 22, 2016, 6:17 PM roger peppe > > wrote:
>>
>>> I don't think I'd object if we added a new builtin function called "ref" 
>>> with the above semantics. It worked pretty well in Limbo as an operator.
>>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[roger peppe]

How would new syntax be better than a built-in function with exactly the
semantics you are after and shorter to type to boot?

On 23 Oct 2016 01:50, "Nate Finch"  wrote:

> I'd much rather have syntax that just works rather than another built-in
> function.
>
> On Sat, Oct 22, 2016, 6:17 PM roger peppe  wrote:
>
>> When I need to do this, I find it's only a very minor annoyance to define:
>>
>> func newInt(i int) { return  }
>>
>> If Go ever got generics, this would probably be trivial to write
>> generically, for example:
>>
>> func Ref[T](x T) *T { return  }
>>
>> I don't think I'd object if we added a new builtin function called "ref"
>> with the above semantics. It worked pretty well in Limbo as an operator.
>>
>> On 21 Oct 2016 22:44, "Nate Finch"  wrote:
>>
>> Perhaps regular was the wrong choice of phrasing.  From an end-user's
>> perspective, it makes the language more consistent, rather than having
>> {v} work for some of the more complex values of T, but not for the more
>> simple values of T.
>>
>> On Fri, Oct 21, 2016 at 3:59 PM Jan Mercl <0xj...@gmail.com> wrote:
>>
>> On Fri, Oct 21, 2016 at 9:20 PM Nate Finch  wrote:
>>
>> > And, I would argue, it actually makes the language slightly more
>> regular, since now {v} works for just about everything (possibly
>> everything?).
>>
>> Taking the address of an addressable thing is the regular proper. Taking
>> address of a non-addressable things, even though practical, is syntactic
>> sugar. Enlarging the surface of the later irregularity cannot make anything
>> more regular.
>>
>> --
>>
>> -j
>>
>> --
>>
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Nate Finch]

I'd much rather have syntax that just works rather than another built-in
function.

On Sat, Oct 22, 2016, 6:17 PM roger peppe  wrote:

> When I need to do this, I find it's only a very minor annoyance to define:
>
> func newInt(i int) { return  }
>
> If Go ever got generics, this would probably be trivial to write
> generically, for example:
>
> func Ref[T](x T) *T { return  }
>
> I don't think I'd object if we added a new builtin function called "ref"
> with the above semantics. It worked pretty well in Limbo as an operator.
>
> On 21 Oct 2016 22:44, "Nate Finch"  wrote:
>
> Perhaps regular was the wrong choice of phrasing.  From an end-user's
> perspective, it makes the language more consistent, rather than having
> {v} work for some of the more complex values of T, but not for the more
> simple values of T.
>
> On Fri, Oct 21, 2016 at 3:59 PM Jan Mercl <0xj...@gmail.com> wrote:
>
> On Fri, Oct 21, 2016 at 9:20 PM Nate Finch  wrote:
>
> > And, I would argue, it actually makes the language slightly more
> regular, since now {v} works for just about everything (possibly
> everything?).
>
> Taking the address of an addressable thing is the regular proper. Taking
> address of a non-addressable things, even though practical, is syntactic
> sugar. Enlarging the surface of the later irregularity cannot make anything
> more regular.
>
> --
>
> -j
>
> --
>
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[roger peppe]

When I need to do this, I find it's only a very minor annoyance to define:

func newInt(i int) { return  }

If Go ever got generics, this would probably be trivial to write
generically, for example:

func Ref[T](x T) *T { return  }

I don't think I'd object if we added a new builtin function called "ref"
with the above semantics. It worked pretty well in Limbo as an operator.

On 21 Oct 2016 22:44, "Nate Finch"  wrote:

> Perhaps regular was the wrong choice of phrasing.  From an end-user's
> perspective, it makes the language more consistent, rather than having
> {v} work for some of the more complex values of T, but not for the more
> simple values of T.
>
> On Fri, Oct 21, 2016 at 3:59 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>> On Fri, Oct 21, 2016 at 9:20 PM Nate Finch  wrote:
>>
>> > And, I would argue, it actually makes the language slightly more
>> regular, since now {v} works for just about everything (possibly
>> everything?).
>>
>> Taking the address of an addressable thing is the regular proper. Taking
>> address of a non-addressable things, even though practical, is syntactic
>> sugar. Enlarging the surface of the later irregularity cannot make anything
>> more regular.
>>
>> --
>>
>> -j
>>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[tylerbunnell]

I agree that a spoonful of syntactic sugar would be wonderful here, though 
I don't have any strong opinions on what form it should take.

On Saturday, October 22, 2016 at 12:31:58 PM UTC-6, Pietro Gagliardi 
(andlabs) wrote:
>
>
> On Oct 22, 2016, at 2:19 PM, Matt Harden  
> wrote:
>
> and [...]int{5}[:] is also illegal (slice of unaddressable value)
>
>
> []int{5} will do the same thing, and I didn't know this until recently but 
> the spec is written such that this even works with named indices:
>
> v := []int{
> 5: 5,
> }
> fmt.Println(len(v)) // prints 6
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Pietro Gagliardi]

> On Oct 22, 2016, at 2:19 PM, Matt Harden  wrote:
> 
> and [...]int{5}[:] is also illegal (slice of unaddressable value)


[]int{5} will do the same thing, and I didn't know this until recently but the 
spec is written such that this even works with named indices:

v := []int{
5:  5,
}
fmt.Println(len(v)) // prints 6

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Matt Harden]

Interesting - &[]int{5}[0] works, but &[...]int{5}[0] doesn't, and
[...]int{5}[:] is also illegal (slice of unaddressable value). I guess I
always thought of []T{x,y,z} as sugar for [...]T{x,y,z}[:] but it's more
like func()[]T{a := [...]T{x,y,z}; return a[:]}()

I agree these are horrible. I just enjoy exploring the dark corners.

On Sat, Oct 22, 2016 at 11:07 AM Matt Harden  wrote:

> &({int}{5}).int also works. :-)
>
> On Sat, Oct 22, 2016 at 9:29 AM Nate Finch  wrote:
>
> Which is effectively the same as my proposal, except horrible.
>
> On Sat, Oct 22, 2016, 12:18 PM Ian Lance Taylor  wrote:
>
>
> You can, of course, write
> p3 := &({5}).i
>
> Ian
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Nate Finch]

Which is effectively the same as my proposal, except horrible.

On Sat, Oct 22, 2016, 12:18 PM Ian Lance Taylor  wrote:

>
> You can, of course, write
> p3 := &({5}).i
>
> Ian
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Ian Lance Taylor]

On Sat, Oct 22, 2016 at 8:42 AM, Matt Harden  wrote:
> I don't like the syntax {0} because int is not a compound type, but
> (0) seems reasonable syntax to me. I do think there is an irregularity
> in the language here:
>
> type Int struct{i int}
> anInt := Int{5}
> p1 := {5} // works
> p2 := // works
> p3 := {5}.i   // compiler error "cannot take the address of Int
> literal.i"
>
> So we can take the address of an Int literal (suggesting that struct
> literals are addressable), and we can take the address of a field of an
> addressable struct, but we can't take the address of a field of a struct
> literal?

That is correct.  Struct literals (and composite literals in general)
are not addressable.  The {v1, v2} syntax is a special syntactic
sugar meaning to allocate a new instance of T, initialize elements,
and return a pointer to the result.  At one point we considered
changing it to (*T){v1, v2} to emphasize that this is really an
expression that returns a value of type *T, but we decided that {v1,
v2} looked better and was clear enough.

You can, of course, write
p3 := &({5}).i

Ian

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Nate Finch]

Perhaps regular was the wrong choice of phrasing.  From an end-user's
perspective, it makes the language more consistent, rather than having
{v} work for some of the more complex values of T, but not for the more
simple values of T.

On Fri, Oct 21, 2016 at 3:59 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Fri, Oct 21, 2016 at 9:20 PM Nate Finch  wrote:
>
> > And, I would argue, it actually makes the language slightly more
> regular, since now {v} works for just about everything (possibly
> everything?).
>
> Taking the address of an addressable thing is the regular proper. Taking
> address of a non-addressable things, even though practical, is syntactic
> sugar. Enlarging the surface of the later irregularity cannot make anything
> more regular.
>
> --
>
> -j
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Jan Mercl]

On Fri, Oct 21, 2016 at 9:20 PM Nate Finch  wrote:

> And, I would argue, it actually makes the language slightly more regular,
since now {v} works for just about everything (possibly everything?).

Taking the address of an addressable thing is the regular proper. Taking
address of a non-addressable things, even though practical, is syntactic
sugar. Enlarging the surface of the later irregularity cannot make anything
more regular.

-- 

-j

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Nate Finch]

That's fair.  But I think it's a worthwhile (and fairly minor) complexity 
to add to the spec to make the language a lot easier to use in some very 
common use cases.  And, I would argue, it actually makes the language 
slightly more regular, since now {v} works for just about everything 
(possibly everything?).  

I'd love to see a bigquery search for variants of declarations of func 
IntP(i int) *int  ... I bet there's a lot of those out there... unless 
people are really doing &[]int{5}[0] ... which is just horrible.

On Friday, October 21, 2016 at 2:53:31 PM UTC-4, Ian Lance Taylor wrote:
>
>
> You are simply defining away the ambiguity by saying that the specific 
> slice composite literal syntax takes precedence over the {v} 
> translates to (*new(T) = v) syntax.  That is a valid approach to take, 
> but it doesn't mean that there is no ambiguity.  And it does mean 
> additional complexity to the spec and to people's understanding of the 
> language. 
>
> Ian 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Ian Lance Taylor]

On Fri, Oct 21, 2016 at 11:39 AM, Nate Finch  wrote:
> I don't think it's ambiguous at all.  We already do different things for
> different T in T{v}.  For slices, the slice is constructed and then each
> value is an item in the slice.  For structs, the struct is constructed and
> then the fields are filled out in declaration order.  We're just adding one
> more rule for single values which is actually really really obvious.
>
> In fact, if anything, we're making it more consistent
>
> &[]int{5}  // this works
> &[1]int{5} // this doesn't
> {5} // this doesn't
>
> Why not make those last two just work?
>
> As xingtao zhao said, &[]interface{}{nil} is not ambiguous.  it's declaring
> a slice, so it fills in one item in the slice and returns the address of the
> slice.

You are simply defining away the ambiguity by saying that the specific
slice composite literal syntax takes precedence over the {v}
translates to (*new(T) = v) syntax.  That is a valid approach to take,
but it doesn't mean that there is no ambiguity.  And it does mean
additional complexity to the spec and to people's understanding of the
language.

Ian

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Nate Finch]

I don't think it's ambiguous at all.  We already do different things for 
different T in T{v}.  For slices, the slice is constructed and then each 
value is an item in the slice.  For structs, the struct is constructed and 
then the fields are filled out in declaration order.  We're just adding one 
more rule for single values which is actually really really obvious.

In fact, if anything, we're making it more consistent

&[]int{5}  // this works
&[1]int{5} // this doesn't
{5} // this doesn't

Why not make those last two just work?

As xingtao zhao said, &[]interface{}{nil} is not ambiguous.  it's declaring 
a slice, so it fills in one item in the slice and returns the address of 
the slice.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Ian Lance Taylor]

On Fri, Oct 21, 2016 at 9:49 AM, Nate Finch  wrote:
>
> I'd really like to see the composite literal syntax extended to work with
> non-composite types, so you could do something like this:
>
> f := Foo{ Count: {5} }

That doesn't work as is, because &[]interface{nil} is ambiguous.  Does
it produce a slice whose length is 1 element and whose single value is
nil (as it does today), or does it produce a nil slice whose length is
zero elements (as it would if we treat {v} as allocating a new T and
initializing it to V).

(This overall issue has been discussed many times before, with no
clear resolution.)

Ian

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Caleb Spare]

I would also like an easier way to construct pointers to ints/bools/strings.

Note that there is a way to write convoluted code that makes e.g.
{3} legal: https://play.golang.org/p/leP5_12IX0
AFAICT this isn't a backwards-compatibility concern, though.

Like you, I would really like &5 to work but I haven't thought through
the kinds of spec changes that would be required to make that possible.

-Caleb

On Fri, Oct 21, 2016 at 10:06 AM, Nate Finch  wrote:
> I had missed that, thanks.  The one response does not really fit the
> problem, though.  There are a lot of times when POS (plain old structs) make
> a really nice UX (or would, if they weren't a pain to handle).  I like
> option types like Dave said, but that's really a whole different beast that
> solves different problems.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Nate Finch]

I had missed that, thanks.  The one response does not really fit the 
problem, though.  There are a lot of times when POS (plain old structs) 
make a really nice UX (or would, if they weren't a pain to handle).  I like 
option types like Dave said, but that's really a whole different beast that 
solves different problems.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] allow {3}, {true} etc

[Konstantin Khomoutov]

On Fri, 21 Oct 2016 09:49:24 -0700 (PDT)
Nate Finch  wrote:

> One of the problems with working with serialization of any kind is
> dealing with unset vs the zero value.  The usual way to get around
> this is to use a pointer, nil is unset, non-nil is set.  But this
> gets annoying when trying to make literal values, because you can't
> take the address of a constant:
> 
> type Foo struct {
> Count *int
> }
> f := Foo{ Count: &5 }
> 
> // cannot take the address of 5

See also the recent thread (14 Oct) on the same topic:
https://groups.google.com/d/topic/golang-nuts/NR_oWflin-Q/discussion

[...]

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] allow {3}, {true} etc

[Nate Finch]

One of the problems with working with serialization of any kind is dealing 
with unset vs the zero value.  The usual way to get around this is to use a 
pointer, nil is unset, non-nil is set.  But this gets annoying when trying 
to make literal values, because you can't take the address of a constant:

type Foo struct {
Count *int
}
f := Foo{ Count: &5 }

// cannot take the address of 5

I get that you can't take the address of a constant, because then you could 
change it, even though it's constant... but the alternatives are really 
clunky.   Sure, you can make a helper function for it, but that just makes 
your API significantly less user-friendly, either you need ugly, basically 
useless functions in your API, or you force your consumers to make those 
functions in every package that consumes yours.  There's a ton of hacks you 
can do to make it work without implementing functions, but they're each 
more horrible than the last: https://play.golang.org/p/9r-JMFSx9C

I'd really like to see the composite literal syntax extended to work with 
non-composite types, so you could do something like this:

f := Foo{ Count: {5} }

This would explicitly tell you that you're making a copy of the constant 5 
and then taking the address of that copy, just like you would here:

type Bar struct {
Val int
}
b := {5}

It seems like it would be intuitive and backwards compatible.

Alternatively, I actually think it would be totally fine and intuitive to 
just let you do &5, but I bet that has less likelihood of being accepted ;)

-Nate

-- 
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.
For more options, visit https://groups.google.com/d/optout.