If we adopt the syntax like &int(0), there will be no ambiguities, even for
the example Ian showed: the two cases will be written as
&[]interface{}(nil) and &[]interface{}{nil}
you may argue that this is confusing, but both []interface{}(nil) and
[]interface{}{nil} are available already.
On Friday, October 21, 2016 at 10:23:04 AM UTC-7, Ian Lance Taylor wrote:
>
> On Fri, Oct 21, 2016 at 9:49 AM, Nate Finch <nate....@gmail.com
> <javascript:>> 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: &int{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 &T{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.
