mutable compile-time data proposal

[Mariusz Gliwiński]

David Nadlinger wrote:
> Could you show a few examples? I'm just curious, because I wrote a
> sizable chunk of D code, often incorporating some form of compile time
> magic, and never felt the need for it.
I'd rather avoid that because code i'm writing isn't a state of art, so you 
might neglect my concrete ideas of solving things (use of tool). 
Furthermore, i'm quite sleepy already so i might forget something, explain 
wrongly. So, i hope i'm not ruining good idea by providing stupid examples.

-- local CT variables, result to standard RT variable.
1) Generate UUIDs of types of messages which are being provided and received 
from various parts of application.

-- global CT variables, not sure if we're talking about that now.
2) Make sure there is only one provider, and one receiver (in couple of 
cases). More generally, validation of application logic, that can be done 
static, but can't be catched up by compiler itself. 

-- local CT variables,
3) There are examples, where i'd like to avoid use of classes (i don't need 
to put them in some container, and treat under superclass API), but i would 
still like to share code (traits). So yes, i'm using mixins, but frequently 
this kind of mixin needs initialization/dispose, which has to be called 
manually by consumer. It leads to many initXTrait on initializer. I'd rather 
like to store function pointers and iterate over it (i'm not even talking 
about add something like this to language).

4) I'd like to generate application interface prototype during compilation 
(serialization of specific parts of AST if i'm not wrong to use this term 
here), and not having to write my own D parser for it. Yeah, i know you 
probably got big WTF in your head while reading this, but these are things 
i'd like to do, and neverthless if it's good or not, those are ideas that 
programmer would like to have a chance to implement.

I'm sure there are more appealing examples, but these are mine, and i'd like 
to just have a possibility to implement them.