On Fri, Oct 21, 2016 at 11:39 AM, Nate Finch <nate.fi...@gmail.com> 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
> &int{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 &T{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.
