Interesting rant about Scala's issues

[Walter Bright]

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
> Warp:
> http://forum.dlang.org/thread/lhf0u6$2r80$1@digitalmars.com?page=3#post-wjjivmmeyeismgkntwsj:40forum.dlang.org

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 strongly
> 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.