Proposal: extend &T{} syntax to other types

[Joshua Liebow-Feeser]

Hi,

I've tried searching for similar proposals, since I figured they probably existed, but couldn't find any. If there are any, just reply with a link and I'll shut up :)

My proposal is this. I like the &T{} syntax for struct initialization, and I don't see why it shouldn't be supported for all types. After all, for any arbitrary T, the following is valid:

t := new(T)
*t = <literal> // such as &T{}

Thus, the &<literal> syntax could work for any type.

First, the motivation. It's not uncommon to need to pass or assign pointer values to newly-initialized values. Currently this requires something like the syntax above, which is somewhat bulkier than the proposed &<literal> syntax.

Second, the plausibility. For many types it would work out of the box since the type is unambiguous:

&true
&"hello"
&[3]int{1, 2, 3}
&[]int{1, 2, 3}
&map[string]int{"one": 1}
&func(r rune) bool { return r == '\n' } // why? who am I to judge...

However, for cases with ambiguous types, it would be consistent with the current implementation to pick a default:

&1 // int
&1.0 // float64
&'1' // int32

And for types other than the default, a conversion would be sufficient (though a bit more unwieldy):

&uint(1)
&float32(1)

Thoughts?
Cheers,
Josh

[Dan Kortschak]

"func tPtr(v T) *T { return &v }" once and "tPtr(x)" where you need the pointer type with a value works pretty well.

[Ian Lance Taylor]

On Sun, Mar 29, 2015 at 1:00 AM, Joshua Liebow-Feeser <he...@synful.io> wrote:
>
> I've tried searching for similar proposals, since I figured they probably
> existed, but couldn't find any. If there are any, just reply with a link and
> I'll shut up :)
>
> My proposal is this. I like the &T{} syntax for struct initialization, and I
> don't see why it shouldn't be supported for all types. After all, for any
> arbitrary T, the following is valid:
>
> t := new(T)
> *t = <literal> // such as &T{}
>
> Thus, the &<literal> syntax could work for any type.

This has been discussed before, along with other permutations of
composite literals, new, and make. I don't think anybody is really
happy with permitting expressions like &1; treating that as allocating
new memory and coying 1 into it makes &1 very different from &v. It
also means that &x[i] is very different depending on whether x is a
slice or a map, and that is a kind of confusion we really don't want.

The current composite literal pointer syntax is arguably misleading,
and should probably have been (*T){vals}.

Ian

[Joshua Liebow-Feeser]

Ah that makes sense - thanks for the clarification!