On Mon, Jul 25, 2016 at 9:10 AM Sam Whited <s...@samwhited.com> wrote:
> On Mon, Jul 25, 2016 at 11:05 AM, T L <tapir....@gmail.com> wrote:
> > Then why
> >
> > T{...}
> >
> > can't be a syntactic sugar for
> >
> > tmp := T{...}
> > tmp
> >
> > and tmp is an okay receiver.
> > :P
>
> It is (effectively)
Not so. The actual code tmp := T{...} would define a variable of type T,
which we could (implicitly) take the address of. So T{} doesn't work like a
syntactic sugar for the two lines. Anyway, that sugar would be recursive:
the expansion of T{...} includes T{...} itself! The expansion of (&T{...})
doesn't have this problem; it involves T{...} but not &T{...}.
I think the intuitive answer is that with &T{...} you are explicitly
requesting an address, so the compiler gives you one (instead of declaring
it a syntax error). With T{...}, any pointer method would potentially
modify the value, but the value is going to be thrown away (it's not stored
in a variable). So there's no point in modifying it. We reject this to
prevent hard-to-find bugs. And if you really want to call a pointer method
on a temporary value like that, you can add 3 characters &().
--
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.
