about the new const regime

[Daniel919]

(dmd 2.009)

What's the difference between "const T" and "invariant T", if T is a 
value type (builtin type or struct)?

Value types are always a copy and never refer to anything.
So a const(T) can't be changed.

Example:
typeid(string) == "invariant(char)[]" (default)

string s = "bla";
s[0] = 'x'; //Error, cannot change a invariant(char)
But then, where is the difference to const(char)?

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?


About enum:
Instead of the current "abuse" of enum to also define values that take 
no space, I would like a new keyword, which can be used more general:

meta

metaprogramming <=> compile time programming
meta <=> compile time

meta x = 1; <=> meta int x = 1;
x is a compile time value of type int.

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


This could also help to make a better distinction:
class Foo { static int x; }
means x is not bound to an object. using static this(), x can be 
assigned at runtime

static if( ... ) ...
means evaluate the if at compile time

With the new keyword, it could be renamed to
meta if( ... ) ...

static <=> not bound to an object
meta <=> compile time


Best regards and happy new year,
Daniel