Why constant is not addressable in golang?

[chou]

I guess that const will be substitute literally at compile time

for performance improvements. So there is not such variable in

run time.

Is it right?

[Axel Wagner]

If a constant was addressable, you could do

const x = 42

x = 23

fmt.Println(x) // 23

so a constant wouldn't be constant anymore. The minimum Go would need, to make constants addressable would be some notion of const-pointers (that is, pointers which don't allow modification of the pointee).

May I ask why it would be interesting to take the address of a constant?

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[chou]

Thanks for your explaination, I was just curious about the language constraint details.

在 2017年8月21日星期一 UTC+8下午2:16:25，Axel Wagner写道：

If a constant was addressable, you could do

const x = 42

x = 23

fmt.Println(x) // 23

so a constant wouldn't be constant anymore. The minimum Go would need, to make constants addressable would be some notion of const-pointers (that is, pointers which don't allow modification of the pointee).

May I ask why it would be interesting to take the address of a constant?

On Mon, Aug 21, 2017 at 7:23 AM, chou <lock...@gmail.com> wrote:

I guess that const will be substitute literally at compile time

for performance improvements. So there is not such variable in

run time.

Is it right?

--
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...@googlegroups.com.

[Jérôme LAFORGE]

> May I ask why it would be interesting to take the address of a constant?

I have been already faced to this case. I usually use go swagger to generate the model from swagger spec. Go swagger generates some structure with field pointer (for example for string) where I always put the same value. The workaround, that I usually use, is to use global variable instead of global constant.

[Konstantin Khomoutov]

One of the reasons for this is that constants in Go have properties
which set them apart from values:

- For numerics, they are allowed (and enforced to a certain extent)
to have size and/or precision way larger than of the regular types
supported by the language.

That is

const onethird = 1 / 3

has greater precision than

onethird := float64(1) / 3

and this may affect calculations done on floating-point numbers.
See for instance [2] for a recent example on why this matters.
[3] is an in-depth explanation of those effects, and [4] is a gentler
one.

- Constant are "almost typeless": they have default type for their
literal value (say, int for the literal 42 or string for the literal
"42") but the compiler allows a much greater freedom when you assign
a constant to a variable (which has exact type).

Say, in Go, it's impossible to do

i := 0
uint32 j := i

but it's perfectly valid to do

const i = 0
uint32 j := i

As you can see, having these properties appears to be incompatible
with actually storing the values of the constants in some R/O memory
and making them addressable.

Please read [1] to get full grasp on constants in Go.

1. https://blog.golang.org/constants
2. https://groups.google.com/d/topic/golang-nuts/XP-_nRWjKnM/discussion
3. http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
4. http://floating-point-gui.de/

[Jan Mercl]

On Mon, Aug 21, 2017 at 1:46 PM Konstantin Khomoutov <kos...@bswap.ru> wrote:

> That is
>
> const onethird = 1 / 3
>
> has greater precision than
> 
> onethird := float64(1) / 3

Zero does not seem to have greater precision than 0.3333333333333333 when approximating the real number 1/3.

--

-j

[Konstantin Khomoutov]

On Mon, Aug 21, 2017 at 12:56:19PM +0000, Jan Mercl wrote:

>> That is
>>
>> const onethird = 1 / 3
>>
>> has greater precision than
>>
>> onethird := float64(1) / 3
>
> Zero does not seem to have greater precision than 0.3333333333333333 when
> approximating the real number 1/3.

IMHO, the less smart-ass responses the list would see, the better.

But I see your point, thanks.

To the OP: the first statement should have been

const onethird = 1.0 / 3

instead.

By the way, currently defined limits the compliant Go compilers must
support with regard to constants, can be found in [1].

1. https://golang.org/ref/spec#Constants