:), but seriously using __LINE__ or __FILE__ to create unique ids just doesn't cut it.On 12/28/11 12:22 PM, Martin Nowak wrote:On Wed, 28 Dec 2011 15:00:10 +0100, Gor Gyolchanyan <[email protected]> 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
On Wed, 28 Dec 2011 19:51:42 +0100, Andrei Alexandrescu
<[email protected]> wrote:
- mutable compile-time data proposal Gor Gyolchanyan
- Re: mutable compile-time data proposal Martin Nowak
- Re: mutable compile-time data proposal Andrei Alexandrescu
- Re: mutable compile-time data proposal Gor Gyolchanyan
- Re: mutable compile-time data proposal Martin Nowak
- Re: mutable compile-time data proposal Andrei Alexandrescu
- Re: mutable compile-time data proposal Mariusz Gliwiński
- Re: mutable compile-time data proposa... Walter Bright
- Re: mutable compile-time data proposa... David Nadlinger
- Re: mutable compile-time data pr... Mariusz Gliwiński
- Re: mutable compile-time dat... Gor Gyolchanyan
- Re: mutable compile-time... Jonathan M Davis
- Re: mutable compile-time... Gor Gyolchanyan
