add support for const struct values

[gopherbot]

by kaushansky:

Const structs could provide a simple may to implement type-safe enums. e.g
type T struct { value int }
 const (
   A T = T{iota};
   B;
   C
 )
Currently, compiler complains that T{iota} is not a constant expression.

[griesemer]

Comment 1:

Owner changed to g...@golang.org.

Status changed to Thinking.

[rsc]

Comment 2:

Labels changed: added languagechange.

[robpike]

Comment 3:

Consts are just not composites in the thinking behind the language.  This may be an
attractive hypothetical 
feature but it doesn't sit right in the context of the existing language and opens up
new meanings of 'const'.

Status changed to WontFix.

[extemporalgenome]

Comment 4:

Although allowing new type kinds to be constants still may not be justifiably useful,
it's now rather trivial to describe what could be reasonably allowable as a const:
Any type for which equality is fully defined could be safely be the type of a constant
value, with the transitive exception being pointers (so neither *struct{int} nor
struct{*int} would be valid constant types), and all constants would remain
non-addressable.
The implications of this would be that arrays and structs following the above rules
could be used in constant declarations, and those constants could in turn be used as map
keys, passed to functions, or stored in variables following the normal rules, since
those operations always involve copies, and all uses, valid or invalid, would be fully
verifiable at compile-time.

[griesemer]

Comment 5:

You are correct that one could probably extend the notion of constants to composite
types. One probably would exclude not just pointers, but all reference types. So
constants could be all composite value types (structs, arrays) where the element types
themselves are types that can have constant values. Naturally, one would want constant
composite literals of those types. Operations such as field selection and array indexing
with constant index on such constant structs and arrays should probably return constant
values again. The compiler would have to represent internally such structs and arrays
such that all const operations could be executed at compile time.
I don't think this would open a new meaning of "const" - I think it would simply extend
it to more types than just the basic types. It would still permit exact representation
and evaluation at compile time.
That said, I am not sure there's enough "bang for the buck": For one, there's a
significant amount of extra language rules for this extended const concept which does
not seem super-important: I can't think of a lot of code that would benefit from being
able to "constant-fold" field selections or constant array indices. Furthermore,
whenever such constant structs and arrays are used as a whole, they would have to be
"materialized" in memory anyway, and thus loose any "memory advantage" that might exist.
Also, the concept doesn't extend orthogonally to _all_ composite literals (what about
maps? arguably they should be included, but I think that would require quite some work
when used in place of non-constant maps). Finally, there would be quite a bit of
compiler work needed: for instance, a type checker now would have to be able to
represent a new class of constants, requiring additional data structures, and operations
on them.
None of this is particularly difficult to do, but it adds enough extra complexity for a
little used feature that it is probably not worth it (as you point out yourself).