Implicit enum conversions are a stupid PITA

[BCS]

Hello Yigal,

> I meant implicit, sorry about that. The pascal way is definitely the
> correct way. 

Wrong. It is not "definitely" the correct way because there are many smart 
people who disagree. It might *be* the correct way, but it that has yet to 
be shown.

> what's the semantics in your opinion of ('f' + 3) ? what
> about ('?' + 4)? making such arithmetic valid is wrong.

The above will depend on the underlying system (because we are talking D, 
that would be UTF). The first will result in the value three grater than 
the value used to represent 'f' (in UTF, 'i'). The same happens for the second 
with suitable substations.

>>> The fact that D has 12 integral types is a bad design, why do we
>>> need so many built in types? to me this clearly shows a need to
>>> refactor this aspect of D.
>>> 
>> Which would you get rid of? (13, I forgot bool!)
>> 
>> bool
>> byte
>> ubyte
>> short
>> ushort
>> int
>> uint
>> long
>> ulong
>> char
>> wchar
>> dchar
>> enum
>
> you forgot the cent and ucent types and what about 256bit types?
> 
> Here's How I'd want it designed:
> 
> First of, a Boolean type should not belong to this list at all and
> shouldn't be treated as a numeric type.

Agree, and it isn't for the most part.

> 
> Second, there really only few use-cases that are relevant
> 
> signed types for representing numbers:
> 1) unlimited integral type - int

Very rare and expensive. This, IMHO, should not be a built in type

> 3) user defined range: e.g. [0, infinity) for positive numbers, etc..

Also rare and expensive for most uses. Again, not built in.

[reordered a bit]

> 2) limited integral type  - int!(bits), e.g. int!16, int!8, etc..
> unsigned bit-packs:
> 4) bits!(size), e.g. bits!8, bits!32, etc..

This would make it look like int!13 and int!16 are both valid and similarly 
costly. If you do make int!13 valid how will it pack in arrays? (Hint: if 
it doesn't pack, I see no more value in it than in a range type, see comment 
to item 3) Will you be able to take a pointer to any element? (Hint: the 
problems with that are why D dropped the bit type.)

When you get right down to it, the types supported by hardware are fairly 
standard (8,16,32,64,... bits signed and unsigned) so why shouldn't the language 
support them directly? I will grant that there are reasons to do what you 
are suggesting, but I don't think they are valid reason with regards to the 
language the D is trying to be.

> of course you can define useful aliases, e.g.
> alias bits!8 Byte;
> alias bits!16 Word;
> ..
> or you can define the aliases per the architecture, so that Word above
> will be defined for the current arch (I don't know what's the native
> word size on say ARM and other platforms)

C more or less has that with int. That D dropped the "what size is int" problem 
is a good thing in my book.

> char and relatives should be for text only per Unicode, (perhaps a
> better name is code-point). for other encodings use the above bit
> packs, e.g.
> 
> alias bits!7 Ascii;
> 
> alias bits!8 ExtendedAscii;
> 
> etc..

D defines text to be unicode. Unicode is a sequence of numbers. It's all 
well defined and whatnot so allowing the programmer to handle them as numbers 
is a must as far as I'm concerned.

Finally, none of that part about integers has anything to do with implicit 
casts. If anything, it would make it harder as you now have even more types, 
not less. 

> 
> enum should be an enumeration type. You can find an excellent
> strongly-typed  design in Java 5.0
> 
-- 
... <IXOYE><