On Mon, Aug 22, 2016 at 9:40 AM, <con...@superhuman.com> wrote:
>
> I've been using a typedef of
>
> type MaybeTimestamp *int64
>
> so we can JSON encode timestamps correctly, see
> https://medium.com/coding-and-deploying-in-the-cloud/time-stamps-in-golang-abcaf581b72f
> for inspriation
>
> I was surprised that the following didn't work (see
> https://play.golang.org/p/1QQylqTLkB):
>
> func NewMaybeTimestamp(t time.Time) MaybeTimestamp {
> return &t.Unix()
> }
>
> // fails with:
> // tmp/sandbox449672725/main.go:14: cannot take the address of t.Unix()
>
> I can fix this by introducing a temporary variable:
>
> func NewMaybeTimestamp(t time.Time) MaybeTimestamp {
> temp := t.Unix()
> return &temp
> }
>
> Seeing as this is the obvious solution to this problem, I was pretty
> disappointed that the compiler couldn't insert the temporary for me.
>
> Is this something that should change, or is it just a limitation hard-coded
> by the compatibility guarantee?
There is no compatibility guarantee issue here, as adding this feature
would not break any existing working programs.
However, in my opinion, it should not be added. In general, the &
operator takes the address of some existing variable. There is one
exception: using &T{} to create a composite literal and takes its
address. You are suggesting adding another exception &f() should call
the function, store the value somewhere in memory, and return the
address of that memory. This is meaningful and I don't see any reason
why it wouldn't work. But it's cryptic, and it's rarely useful. I
think it's OK to use a variable.
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.
