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.
