Implicit enum conversions are a stupid PITA

[yigal chripun]

It seems that on a conceptual level we are in complete agreement. 
the difference seems to be that you want to push some things onto the user which I think the language should provide.

Walter Bright Wrote:

> yigal chripun wrote:
> > Walter Bright Wrote:
> > 
> >> Yigal Chripun wrote:
> >>> Walter Bright Wrote:
> >>>> 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.
> >> Yes, that is exactly the opinion of Pascal. As I said, I've programmed in 
> >> Pascal, suffered as it blasted my kingdom, and I don't wish to do that
> >> again. I see no use in pretending '?' does not have a numerical value that
> >> is very useful to manipulate.
> >> 
> > 
> > '?' indeed does *not* have a single numerical value that identiies it in a
> > unique manner. You can map it to different numeric values based on encoding
> > and even within the same encoding this doesn't always hold. See normalization
> > in Unicode for different encodings for the same character.
> 
> 
> That's true, '?' can have different encodings, such as for EBCDIC and RADIX50. 
> Those formats are dead, however, and ASCII has won. D is specifically a Unicode 
> language (a superset of ASCII) and '?' has a single defined value for it.
> 
> Yes, Unicode has some oddities about it, and the poor programmer using those 
> characters will have to deal with it, but that does not change that quoted 
> character literals are always the same numerical value. '?' is not going to 
> change to another one tomorrow or in any conceivable future incarnation of Unicode.
> 

while it's true that '?' has one unicode value for it, it's not true for all sorts of diacritics and combine code-points. So your approach is to pass the responsibility for that to the end user which in 99.9999% will not handle this correctlly. 

> >> Naturally, either everyone invents their own aliases (like they do in C
> >> with its indeterminate int sizes), or they are standardized, in which case
> >> we're back to pretty much exactly the same point we are at now. I don't see
> >> where anything was accomplished.
> >> 
> > Not true. say I'm using my own proprietary hardware and I want to have
> > bits!24. How would I do that in current D?
> 
> You'd be on your own with that. I had a discussion recently with a person who 
> defended C's notion of compiler defined integer sizes, pointing out that this 
> enabled compliant C compilers to be written for DSLs with 32 bit bytes. That is 
> pedantically correct, compliant C compilers were written for it. Unfortunately, 
> practically no C applications could be ported to it without extensive modification!
> 
> For your 24 bit machine, you will be forced to write all your own custom 
> software, even if the D specification supported it.
> 
I completely agree with you that the C notion isn't good for integral types. It would only make sense when you use bits kind of type, where you'd see size_t in D (not common in user code).
Of course any software that depends on a specifc size, e.g. bits!32 will need to be extensively modified if it's ported to an arch which requires a different size. But I'm talking about the need to define bits!(T) myself instead of having it in the standard library.

> 
> > what if new hardware adds support
> > for larger vector ops and 512bit registers, will we now need to extend the
> > language with another type?
> 
> D will do something to accommodate it, obviously we don't know what that will be 
> until we see what those types are and what they do. What I don't see is using 
> 512 bit ints for normal use.
> 

There's another issue here and that's all those types are special cases in the compiler and handled separately from library types. 
Had the stdlib provided the templeted types it would have allowed to use them in more generic ways instead of special caseing them everywhere. 

> 
> 
> >>> char and relatives should be for text only per Unicode, (perhaps a better
> >>>  name is code-point).
> >> There have been many proposals to try and hide the fact that UTF-8 is
> >> really a multibyte encoding, but that makes for some pretty inefficient
> >> code in too many cases.
> > 
> > I'm not saying we should hide that, on the contrary, the compiler should
> > enforce unicode and other encodings should use a bits type instead. a
> > [w|d]char must always contain a valid unicode value. calling char[] a string
> > is wrong since it is actually an array of code-points which is not always a
> > valid encoding. a dchar[] is however a valid string since each individual
> > dchar contains a full code-unit.
> 
> Conceptually, I agree, it's wrong, but it's not practical to force the issue.

> 
> 
> >>> enum should be an enumeration type. You can find an excellent
> >>> strongly-typed design in Java 5.0
> >> Those enums are far more heavyweight - they are a syntactic sugar around a
> >> class type complete with methods, interfaces, constructors, etc. They
> >> aren't even compile time constants! If you need those in D, it wouldn't be
> >> hard at all to make a library class template that does the same thing.
> >> 
> > 
> > They aren't that heavy weight. Instead of assigning an int to each symbol you
> > assign a pointer address which is the same size.
> 
> No, it's not the same. A compile time constant has many advantages over a 
> runtime one. Java creates an inner class for each enum member, not just the enum 
> itself! It's heavyweight.
> 
> > Regarding the compile time
> > property: for an int type: const int a = 5; //compile time the same should
> > apply to enums as well.
> 
> Having a runtime pointer to an inner class for each enum value is far from the 
> advantages of a compile time constant.
> 
I don't understand this point - can't the inner class be put in the data segment? Also, why not use structs instead of classes? 
> 
> > The problem with the library solution is that it can't provide the syntax
> > sugar for this.
> 
> It can get pretty close. Java has poor abstraction facilities, and so building 
> it into the language was the only solution.

how close can it get? I don't mind having this in the stdlib instead of in the language if it's pleasent enough on the eyes.