about the new const regime

[Janice Caron]

On 1/1/08, Daniel919 <Daniel919 at web.de> wrote:
> (dmd 2.009)
>
> What's the difference between "const T" and "invariant T", if T is a
> value type (builtin type or struct)?

Pretty much none. In both cases, the type is invariant in practice.


> If there really is no difference, shouldn't string be "const(char)[]"
> then? And maybe invariant(T) should be an error, when T is a valuetype?

You can do

    const x = 5;
    invariant x = 5;

If the compiler is smart enough, in both cases, x will have type
invariant(int). If the compiler doesn't try to be smart, then x will
have type const(int) and invariant(int) respectively. Having two ways
to say the same thing may seem redundant, but for reasons of generic
programming, neither of them should be considered an error.


> enum { red, green, blue } //<=>
> meta red = 0, green = 1, blue = 2;

For those of us who support "real enums", those two are not
equivalent, since "real enums" make no numerical value available to
the programmer. You have no choice /but/ to use the enumerated names.

But of course, for that very reason, many (myself included) have
argued that a different keyword for manifest constants would be a good
idea (possibly paving the way for "enum" to be retooled to make "real
enums" in the future).

"meta" is as good a name as any, although I think I like "manifest"
better. I'd be happy with either. But right now, neither is on the
table.