On 4/4/2014 3:24 AM, bearophile wrote:
You see I care of casts also from the little casts statistic I've done on your

Most of the casts in Warp come from the workarounds I had to do to get around the auto-decode of std.array.front(). I have designed byChar, byWchar and byDchar ranges for Phobos to get around this issue, but that is stalled now because of the messed up design of ranges.

None of that has anything to do with enums.

But since I follow D development and I write D code I don't remember any kind of
discussion regarding the specific disadvantages of a stronger typed enum.

Here's one:

  enum Index { A, B, C }
  T[Index.max] array; // Error: Index.max is not an int
  array[B] = t;   // Error: B is not an int

And another:

  array[A + 1] = t; // Error: incompatible types Index and int

And another:

  enum Mask { A=1,B=4 }

  Mask m = A | B;   // Error: incompatible operator | for enum

and on it goes. These are routine and normal uses of enums.

This means answering questions like: what does it happen if D enums become 
typed? How many casts is this going to cause in D code? Is it true that such
enum casts are going to be worse than type unsafety of the current design?

Yes, because I have to fill the above code with cast(int), and you are well aware that such blunt casting destroys all type safety.

And besides, even if such strongly typed enums were a good idea, making such a change would be an utter disaster for existing code. It is out of the question.

Reply via email to