Re: mutable compile-time data proposal

[Andrei Alexandrescu]

On 12/28/11 12:22 PM, Martin Nowak wrote:

On Wed, 28 Dec 2011 15:00:10 +0100, Gor Gyolchanyan
<gor.f.gyolchan...@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.

enum Masks
{
    __iota = __LINE__, A = (1 << 0),
    B = (1 << __LINE__ - __iota),
    C = (1 << __LINE__ - __iota),
    DMask = (0b11 << __LINE__ - __iota), D0 = (1 << __LINE__ - __iota),
    D1 = (1 << __LINE__ - __iota),
}

Yeah, I'm jesting. Or am I???


Andrei