mutable compile-time data proposal

[Martin Nowak]

On Wed, 28 Dec 2011 15:00:10 +0100, Gor Gyolchanyan  
<gor.f.gyolchanyan at gmail.com> wrote:

> This is something I was thinking about for a long time now.
>
> There seems to be absolutely no difference between T, const(T) and
> immutable(T) if T is a compile-time value (a enum or a local in CTFE).
> The possibility to mutate compile-time values (at compile time, of
> course) would allow very convenient techniques to be used for a number
> of purposes.
> And since in my hypothetical D compile-time data can be mutated, then
> a compile-time static this is required (especially for the next
> example).
> For instance, here's something I'd love to be able to do:
>
> class Base
> {
>     mixin template Register()
>     {
>         ctStaticThis() // a placeholder for the real compile-time static  
> this
>         {
>                 Derived = TypeTuple!(Derived, typeof(this));
>         }
>     }
>
>     enum Derived = TypeTuple!();
> }
>
> class Derived1: Base
> {
>     mixin Register;
> }
>
> class Derived2: Base
> {
>     mixin Register;
> }
>
> static assert(is(Base.Derived == TypeTuple!(Base, Derived1, Derived2)));
>
> Similar things would allow to quickly build extremely powerful and
> useful compile-time information, which is currently not possible to
> build.
> If mutable compile-time data is implemented, the entire compile-time
> computation in D would become just like the run-time one.
>

I'd really like to see such a construct.

enum __iota;

enum Masks
{
     A = (1 << __iota++),
     B = (1 << __iota++),
     C = (1 << __iota++),

     DMask = (0b11 << __iota),
     D0 = (1 << __iota++),
     D1 = (1 << __iota++),
}

static assert(__iota <= 32);

Now this would depend on the order of semantic so it's not feasible.