const initializer must be constant

[Kent Loobey]

Why is this not allowed?

const AXONFIRESEQ = [5] uint32 {0x000000, 0xff0000, 0x00ff00, 0x0000ff, 0xffffff};

[Dimiter "malkia" Stanev]

http://golang.org/doc/go_spec.html#Constants
"There are boolean constants, integer constants, floating-point
constants, and string constants. Integer and floating-point constants
are collectively called numeric constants."

[Kent Loobey]

On Sunday 13 December 2009 10:03:19 Dimiter "malkia" Stanev wrote:
> http://golang.org/doc/go_spec.html#Constants
> "There are boolean constants, integer constants, floating-point
> constants, and string constants. Integer and floating-point constants
> are collectively called numeric constants."

I read that before. I'm guessing that "go" just doesn't support an array of
constants and I am wondering why not.

If it is a compiler speed issue than I am good with that. I was just
wondering.

[hong]

> I read that before.  I'm guessing that "go" just doesn't support an array of
> constants and I am wondering why not.

One reason is Go does not support "const". If you pass constant array
to
a function, you have to allow caller to modify it or you have to pass
a copy
of it. None of them is a good choice. To support constant array or
struct,
it requires language change and runtime change (putting constant into
read-only data segment). I don't know if it is going to happen.

Hong

[Qtvali]

Is this bad to have const input of functions? So that the function
couldn't change that input anyway. Then, copy could be done manually
in some cases. Many functions do not need to change an input.

[Dimiter "malkia" Stanev]

That would put uncertainty at every level. Either it has to be always
guaranteed, or just don't do it.

One of the reasons I don't like C++'s const - yes it's there, yet I
can cast and modify it. How can I be sure? How can I convince the rest
of the people using C++ that it's a bad practice.

[Qtvali]

On Dec 14, 8:08 am, "Dimiter \"malkia\" Stanev" <mal...@gmail.com>
wrote:

> That would put uncertainty at every level. Either it has to be always
> guaranteed, or just don't do it.
>
> One of the reasons I don't like C++'s const - yes it's there, yet I
> can cast and modify it. How can I be sure? How can I convince the rest
> of the people using C++ that it's a bad practice.

Someone in those lists said that slices of Go are type-safe because
current processors allow it with top speed. Having const input of
functions should be simpler - in C++, you have pointer arithmetics; in
Go, you have not (or they are specifically marked as unsafe, so one is
warned about breaking the code).

[SnakE]

2009/12/14 hong <ho...@google.com>

> I read that before.  I'm guessing that "go" just doesn't support an array of
> constants and I am wondering why not.

One reason is Go does not support "const". If you pass constant array
to a function, you have to allow caller to modify it or you have to pass
a copy of it. None of them is a good choice.

I thought consts were a sort of named literals.  Therefore I'd expect a const array to work exactly like a literal with the same contents would.  Are there any problems with this approach?

[hong]

> I thought consts were a sort of named literals.  Therefore I'd expect a
> const array to work exactly like a literal with the same contents would.
> Are there any problems with this approach?

Strings and numbers are immutable, so they are safe to use them
as constants. But there are no immutable type of array etc, so you
can't prevent other people from modifying your constants.

Hong

[Qtvali]

On Dec 14, 9:23 pm, SnakE <snake.sc...@gmail.com> wrote:
> I thought consts were a sort of named literals.  Therefore I'd expect a
> const array to work exactly like a literal with the same contents would.
> Are there any problems with this approach?

You can use var instead of const.

In case you want them to be stored as consts, you can make named
constants from array elements and then declare an array containing
them - compiler, anyway, will take elements as constants in both case;
but array itself as list of mutable pointers will be not const.

[SnakE]

2009/12/14 hong <ho...@google.com>

But the language prevents people from modifying array literals, right?  It just allocates a new array every time a literal is used.  When I say "work exactly like a literal" I mean exactly.  Let const allocate a new array like if it were a C macro with an array literal inside.

[Hong Zhang]

> But the language prevents people from modifying array literals, right?  It
> just allocates a new array every time a literal is used.  When I say "work
> exactly like a literal" I mean exactly.  Let const allocate a new array like
> if it were a C macro with an array literal inside.

It is up to Go authors to decide. I would love to see const arrays and structs.

Hong

[Qtvali]

On Dec 14, 9:54 pm, SnakE <snake.sc...@gmail.com> wrote:
> 2009/12/14 hong <h...@google.com>

> But the language prevents people from modifying array literals, right?  It
> just allocates a new array every time a literal is used.  When I say "work
> exactly like a literal" I mean exactly.  Let const allocate a new array like
> if it were a C macro with an array literal inside.

Go team has several considerations.

One is the following: if it's built in to the language, it has to be
fast. If it's not fast, it has to be not built in.

This is why they have left more important things out - not one, but
many. Were they all built in, you couldn't write anything fast in Go
because of a lot of learning first, what is fast and what is slow.
Because const is supposed to be fastest variable type in a language -
it's usually doing all kinds of precalculations and other speed
optimizations - it shouldn't contain anything before they have figured
out how to make it really fast. Thus, to make it sure you can see if
variable is slow or fast, they have implemented it that way. And "work
exactly like a literal" is syntax error -
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html
...usually statements work like statements and they have a lot of
reasoning behind them, not just a need to make them look like
something they aren't. When you created an engine for something, you
would get the job done as easily and with the same quality as if const
did look like a literal, thus it's not an important feature right now.

Also, const is not a C macro, thus there is no need to follow C
specification.

Which all doesn't mean that I wouldnt like to have some slower and
more convenient things myself, but in this case I dont see the reason,
it's just wanting-because-of-wanting case.

[Ian Lance Taylor]

hong <ho...@google.com> writes:

> One reason is Go does not support "const". If you pass constant array
> to
> a function, you have to allow caller to modify it or you have to pass
> a copy
> of it. None of them is a good choice. To support constant array or
> struct,
> it requires language change and runtime change (putting constant into
> read-only data segment). I don't know if it is going to happen.

Being precise, passing an array to a function copies the array anyhow.
Your argument is a reason to not have const slices. That said, there
are very similar arguments against const arrays: what happens if you
take the address? What happens if you make a slice?

Ian

[Qtvali]

On Dec 14, 10:59 pm, Ian Lance Taylor <i...@google.com> wrote:

> hong <h...@google.com> writes:
> Being precise, passing an array to a function copies the array anyhow.
> Your argument is a reason to not have const slices. That said, there
> are very similar arguments against const arrays: what happens if you
> take the address? What happens if you make a slice?

Wont it help to have just one "const" datatype supposed to be input of
any function before you can pass consts to it.

Also for numerics so that I could create multiprecision integer and
cast it to my own type. Currently max value of uint64 is maximum
integer constant size.

Using const as normal array would require cast and copy.

* Taking slice makes it a const slice - not startup constant, but
immutable except the size.