Implicit enum conversions are a stupid PITA

[Yigal Chripun]

Walter Bright Wrote:

> yigal chripun wrote:
> > here's a simple version without casts: int toString(dchar[] arr) { int temp =
> > 0; for (int i = 0; i < arr.length; i++) { int digit = arr[i].valueOf - 30; //
> > * if (digit < 0 || digit > 9) break; temp += 10^^i * digit; } return temp; }
> > 
> > [*] Assume that dchar has a valueOf property that returns the value.
> > 
> > where's that mess of casts you mention?
> 
> In Pascal, you'd have type errors all over the place. First off, you cannot do
> arithmetic on characters. You have to cast them to integers (with the ORD(c)
> construction).
> 

> > Pascal is hardly the only language without excplicit casts.
> 
> Pascal has explicit casts. The integer to character one is CHR(i), the character 
> to integer is ORD(c).
> 

I meant implicit, sorry about that. The pascal way is definitely the correct way. what's the semantics in your opinion of ('f' + 3) ? what about ('?' + 4)? making such arithmetic valid is wrong.
I'm sure that the first Pascal versions had problems which caused you to ditch that language (they where fixed later). I doubt it though that this had a large impact on Pascal's problems. 

> 
> > ML is also
> > properly strongly typed and is an awesome language to use.
> 
> I don't know enough about ML to comment intelligently on it.
> 
> 
> > 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.
Second, there really only few use-cases that are relevant

signed types for representing numbers:
1) unlimited integral type - int
2) limited integral type  - int!(bits), e.g. int!16, int!8, etc..
3) user defined range: e.g. [0, infinity) for positive numbers, etc..

unsigned bit-packs:
4) bits!(size), e.g. bits!8, bits!32, etc.. 

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)

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

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