using enums as key in associative array

[Jonathan M Davis]

On Tuesday, March 08, 2011 07:40:08 spir wrote:
> On 03/08/2011 03:48 PM, Jonathan M Davis wrote:
> > I really don't understand your problem with module constructors. They're
> > fantastic.
> 
> I may be wrong, but I think this point of view is a "where I can from"
> statement. C's char* are fantastic when you have never used a PL with
> builtin strings. There are languages in which you don't need to list twice
> everything just to have them available at import time.
> 
> // data definition
> X foo;
> Y bar;
> Z baz;
> ...
> static this {
>     foo = ...;
>     bar = ...;
>     baz = ...;
>     ...
> }

In one case, you're declaring a variable. In another, you're giving it a value. 
They're two _very_ different things. In one case, you're telling the compiler 
that a particular variable exists. In the other, you're giving it a value.

Generally, it is ideal to give a variable its initial value (and final value if 
it's not mutable) when you declare it, and there's no question that CTFE is 
currently not as good as we'd like in that regard. However, there are plenty of 
cases where it makes no sense to give a variable its initial value at compile 
time. So, given that D requires that _all_ module variables, class/struct 
variables, and member variables which are directly initialized have that value 
known at compile time, you have to do it separately to do it runtime. Also, 
there are plenty of cases where there are dependcies between variables such that 
you need to actually give them values within a function rather than statically. 
Constructors do a beautiful job of dealing with this problem.

The main alternative is to allow you to set module, class/struct,  and member 
variables directly at runtime. Languages such as C++ and Java do this, and it 
causes a host of problems. The order of initialization isn't necessarily defined. 
It's possible to end up using variables before they're actually initialized. 
Compilation is slower because of all of the interdependencies, whereas in D it's 
possible to parallelize a lot of what the compiler does with declarations, 
because they're not interdependent like they are in C++ or Java. Not to mention, 
if you want to be able to initialize them in a manner which requires you to 
essentially have a function rather than set them directly, then you _need_ 
something like a constructor to initialize them. Also, you don't get compile 
time evaluation of variables in languages like C/C++ and Java like you do in D, 
so _every_ variable is initialized at runtime. The occasional irritation with 
the current implementation problems of CTFE is _well_ worth the gain in compile 
time evaluation.

D uses a model similar to C/C++ and Java, but it improves on it _considerably_ 
by doing things the way it does. The order of initialization in D is _well-
defined_ and not bug-prone. It also lends itself to efficient compilation. Granted, 
until CTFE is able to do anything in SafeD (as its intended to do eventually), 
there are going to be irritating restrictions with regards to what we can and 
can't initialize directly using CTFE, but that's an implementation detail which 
will improve. D's design in this regard is excellent.

- Jonathan M Davis