[go-nuts] Re: Why can't you take the address of a function's return value?

[adonovan via golang-nuts]

On Monday, 29 August 2016 13:36:00 UTC-4, Conrad Irwin wrote:
>
> because of the automatic escape detection, I no longer think of a pointer 
> as being the intrinsic address of a value; rather in my mind the & operator 
> creates a new pointer value that when dereferenced returns the value.
>
 

> With that mental model mixup in place, it's obvious why "&f()" makes sense 
> — it's just creating a new pointer to the value returned by "f()".
>
 
>
If you instead keep in mind that the meaning of "&" is supposed to be 
> closer to "what's the address of this thing?" for the purpose of 
> identity-based equality and reference sharing, it makes more sense to 
> prohibit "&m[k]" or "&f()" because each time you run those you may/will get 
> a new pointer (which is not useful for identity-based equality or reference 
> sharing). It still would be useful for my case which was essentially 
> converting one type to an "optional" type, but maybe that's enough of an 
> edge case that it doesn't matter.
>

The composite literal syntax &T{...} may have led you astray, as it is not 
equivalent to "&" + "T{}".  That is, it doesn't mean "here's an expression 
of type T, give me its address", it means, "create a new variable of type 
T, initialize it, then give me its address".  It's shorthand for:

   p := new(T); *p = T{...}; p

The key thing is that only variables have addresses.  (Escape analysis is 
irrelevant: all of this applies equally to stack and heap variables.)

>

-- 
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.

[go-nuts] Re: Why can't you take the address of a function's return value?

[Conrad Irwin]

On Mon, Aug 29, 2016 at 10:17 AM, wrote:On Friday, 26 August 2016 23:58:53 UTC-4, T L  wrote:And there is also an exception for the counter rule: map elements are not addressable.Just because you can use the assignment syntax m[k]=v to update a map element does not mean a map element is a variable ("addressable").  This is not an exception to a rule. Please adapt it.Compatibility with Go 1.0 means that fundamental changes to the semantics, no matter how sensible or popular, are not going to happen.



-- 
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.

[go-nuts] Re: Why can't you take the address of a function's return value?

[adonovan via golang-nuts]

On Friday, 26 August 2016 23:58:53 UTC-4, T L wrote:
>
> And there is also an exception for the counter rule: map elements are not 
> addressable.
>

Just because you can use the assignment syntax m[k]=v to update a map 
element does not mean a map element is a variable ("addressable").  This is 
not an exception to a rule.
 

> Please adapt it.
>

Compatibility with Go 1.0 means that fundamental changes to the semantics, 
no matter how sensible or popular, are not going to happen.

-- 
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.

[go-nuts] Re: Why can't you take the address of a function's return value?

[T L]

On Sunday, August 28, 2016 at 10:07:49 AM UTC+8, Florin Pățan wrote:
>
> This request, yo take the address of a return value of a function, seems 
> to conflict with the last request made here to standardize and not have 
> exceptions to rules.
>
> And I say this because in Go a function can have multiple return values, 
> most commonly a (type, error) pair.
>
> How should that work then? Add an exception so that single value return 
> functions can be used like this? Add an exception so that when a couple of 
> values are returned then if one of them is error it doesn't take the 
> address for that? What would happen in case of more than two return 
> arguments?
>

The exception is ready added: one return result can be used in expressions. 

-- 
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.

[go-nuts] Re: Why can't you take the address of a function's return value?

[Florin Pățan]

This request, yo take the address of a return value of a function, seems to 
conflict with the last request made here to standardize and not have exceptions 
to rules.

And I say this because in Go a function can have multiple return values, most 
commonly a (type, error) pair.

How should that work then? Add an exception so that single value return 
functions can be used like this? Add an exception so that when a couple of 
values are returned then if one of them is error it doesn't take the address 
for that? What would happen in case of more than two return arguments?

-- 
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.

[go-nuts] Re: Why can't you take the address of a function's return value?

[T L]

On Saturday, August 27, 2016 at 11:34:05 AM UTC+8, T L wrote:
>
>
>
> On Tuesday, August 23, 2016 at 1:25:03 AM UTC+8, con...@superhuman.com 
> wrote:
>>
>> Hey All,
>>
>> 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?
>>
>
> Direct values, including const and temp values, are not addressable. But 
> there is an exception which is described in Ian's answer. 
>
 
>

The counter rule is: variables, including elements of variables, are always 
addressable. 
And there is also an exception for the counter rule: map elements are not 
addressable.

Please adapt it. Almost for every rule in Golang, there are some exceptions.

 

>
>> Conrad
>>
>>

-- 
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.

[go-nuts] Re: Why can't you take the address of a function's return value?

[T L]

On Tuesday, August 23, 2016 at 1:25:03 AM UTC+8, con...@superhuman.com 
wrote:
>
> Hey All,
>
> 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?
>

Direct values, including const and temp values, are not addressable. But 
there is an exception which is described in Ian's answer.
 

>
> Conrad
>
>

-- 
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.