mutable compile-time data proposal

Gor Gyolchanyan gor.f.gyolchanyan at gmail.com
Wed Dec 28 14:54:46 PST 2011


I think you are, because this depends on syntax; blank lines between
them would break it. Still there would be a huge potential use for
that feature.

On Wed, Dec 28, 2011 at 10:51 PM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> On 12/28/11 12:22 PM, Martin Nowak wrote:
>>
>> 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.
>
>
> 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



-- 
Bye,
Gor Gyolchanyan.


More information about the Digitalmars-d mailing list