Compile-time variables

[Kayomn]

>
> Besides this, I tried something with types used as user defined 
> attributes.
> https://dlang.org/spec/attribute.html#uda
>
> Automatic compile time tagging is not my speciality, however, I 
> think is also achievable with mixins somehow?
> But I don't know how to workaround the bug
> https://issues.dlang.org/show_bug.cgi?id=18718
> at this moment...
>
> https://run.dlang.io/is/DmBhO5

> Does the default case handle an unspecified class or does it 
> handle a class which is specified, but is not mentioned in any 
> of previous cases?

So in this example code the switch table is being used for 
loading data serialized into text. If the class cannot determine 
the node ID or it uses the default node type ID (e.g. the Node 
type if super "Node") it will create a simple node, as you can 
always be sure no matter what the type there will be sufficient 
information stored in the data to construct a default Node.

> Another information shortage is: are the tags exclusive or not? 
> So, is it possible that a class has more then one tag (still 
> being unique (tuple))?

ID tags are unique and spsecific to the class type. There 
shouldn't be more than one type ID assigned to one class type.

The idea behind what it is I am doing is I am implementing a 
solution to getting a type index, similar to 
std.variant.Variant.type(). The way that I implemented this in 
C++ is like so:

--------------------------------------------------------------------------------
inline unsigned int getNodeTypeID() {
     static unsigned int lastID = 0;

     return lastID++;
}

template<typename T> inline unsigned int getNodeTypeID() {
     static unsigned int typeID = getNodeTypeID();

     return typeID;
}
--------------------------------------------------------------------------------

In this C++ example I am exploiting the fact that templates are 
generated at compile-time to execute getNodeTypeID for each new 
type instance generated. After initial type generation, whenever 
they are called at runtime they were return the ID assigned to 
that function template instance that was generated at 
compile-time.

It's pretty simple, and to be honest I'm surprised this has been 
causing me such a headache implementing it in D.