proposal: spec: allow constants of arbitrary data structure type

[gopherbot]

by RickySeltzer:

var each1 = []byte{'e', 'a', 'c', 'h'}
    const each2 = []byte{'e', 'a', 'c', 'h'}

The 'var' is accepted, the 'const' is not. This is a defect in the language spec and
design.

1. What is a short input program that triggers the error?
http://play.golang.org/p/Jbo9waCn_h

2. What is the full compiler output?
prog.go:7: const initializer []byte literal is not a constant
 [process exited with non-zero status]

[robpike]

Comment 1:

Issue #6388 has been merged into this issue.

[robpike]

Comment 2:

Labels changed: added priority-someday, languagechange, removed priority-triage, go1.2maybe.

Status changed to Accepted.

[cznic]

Comment 3:

I'm against this. If it would have to have constant semantics then its run time costs
are the same as today, only hidden.
        const c = []byte{1}
        a := c
        a[0] = 42
        b := c
        fmt.Println(b[0] == 1)
The above can print 'true' only if the c's backing array is copied in assignment to 'a',
however the const declaration gives an illusion of always using the same backing array -
like is the case of a string's backing array.
IOW: 1. nothing is gained by const []T and 2. run time costs get hidden and thus
potentially confusing.

[gopherbot]

Comment 4 by RickySeltzer:

If slice constants have this hidden cost problem, could we at least have constant arrays
and arrays of arrays?
 const sentence = [...][...]byte{"a", "series", "of", "pieces", "of", "text"}
1. This should be sufficiently const that it could, in the right environment, go into
rom or the code segment.  That is, be immutable, ideally.
2. I should be able to type it without getting RSI from repeating '[]byte' for every
word.
3. For byte structures like this, it isn't absolutely necessary that we would be allowed
to enter arbitrary runes, although that would be technically feasible, and useful. 
Especially for those who aren't English-language programmers.  And it would be
consistent with the rest of Go.

[gopherbot]

Comment 5 by RickySeltzer:

Change "arbitrary runes" ==> "arbitrary Unicode characters with large code points".

[griesemer]

Comment 6:

Some comments:
1) This is neither a defect of the language nor the design. The language was
_deliberately_ designed to only permit constant of basic types.
2) The implications of such a change are much more far-fetching than meets the eye:
there are numerous open questions that would have to be answered _satisfactorily_; and I
don't think we are there yet.
For instance, if we allow such constants, where is the limit? Do we allow constant maps?
What about constant channels? Constant pointers? Is it just a special case for slices?
etc.
A first step might be to allow constant arrays and structs as long as they are only
composed of fields that can have constant types themselves.
An even smaller step (which I do think we should do) is to make "foo"[i] a constant if i
is a constant (right now it's a non-constant byte).
Finally, note that it's often not very hard for a compiler to detect that a
package-level variable is never modified. Thus, an implementation may choose to optimize
the variable initialization and possibly compute it compile time. At this point, the
const declaration only serves as documentation and for safety; there's no performance
loss anymore.
But again, we have tried to keep the type system (incl. what constants are) relatively
simple so that it doesn't get into the way. It's not clear the benefits are worth the
price in additional complexity.

Status changed to LongTerm.

[gopherbot]

Comment 7 by RickySeltzer:

In many projects I have programmed, there is a need for non-writable initialized data
larger than a single variable.  This is analogous to an 'asm' directive that initializes
bits in the code segment.  Something that the compiler has to do anyway.
Also, embedded systems often need to put data into read-only-memory (ROM).  
This has more to do with storage class than the type system.  Declarations rather like
the following might be simplest:
const (
   data =  []byte("The quick brown fox jumped over the lazy dog.")
   π = float64(3.14159)
   bits = []uint32{0x12345678, 0xBabeAbed}
)
I don't see any additional complexity here.  But it might be easier to introduce a new
modifier, "readonly" to supplement "const", if for some reason the above chokes the
grammar. 
Putting data in the code segment is just my way of saying that it's simple.  Actually,
it would be a security risk.  Anything marked "const" or "readonly" should be NX (Not
eXecutable).

[gopherbot]

Comment 8 by RickySeltzer:

Also, the language and runtime currently make strings immutable.  So the "Hidden cost"
problem in #4, above, already exists.  Just extend this to const.

[cznic]

Comment 9:

@8: No, you cannot do &str[expr], nor you can do str[expr] = expr, but you can of all of
that with a []byte, for example.

[rsc]

Comment 10:

Labels changed: added go1.3maybe.

[gopherbot]

Comment 11 by RickySeltzer:

Ah.  It was a typo on my part to use slice notation []byte, instead of array notation,
[...]byte.  I don't propose constant slices.  I propose constant (initialized) arrays. 
See here: http://play.golang.org/p/eCn6ip--w0.

[rsc]

Comment 12:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 13:

Labels changed: added repo-main.