PhobosWatch: manifest => enum

[Don Clugston]

Walter Bright wrote:
> Jérôme M. Berger wrote:
>>     :(
> 
> Yeah, I figure I'll get fricasseed over that one. The most compelling 
> argument is that we already have 3 ways to declare a constant, adding a 
> fourth gets very difficult to justify. As opposed to a minor extension 
> to enums.

This statement really disturbs me, as this is clearly a major change to an enum.
I think the consequences are quite horrible.

The primary function of enum is to create a TYPE based on a GROUP of related 
INTEGRAL constants. You can abuse the facility to declare integral constants, 
but that's a secondary feature at best. The problem is that using enum for 
abtritrary types is a very poor match for the primary feature of enums.

We don't want to create a type; we don't want a grouping; and the values are not 
integral.

enum : int { A=2, B, C }

Having an enum automatically get the 'next' value is one of the key feature of 
enums, and it relies on the base type being an enumerable type. char [], 
structs, and floating-point types don't have that behaviour. You're guaranteed 
that integral types remain as a special case.

In another post, you mentioned that this would become allowed, to reduce the 
effect of the special case:
enum : float { A=2, B, C }

Which leads to the same nonsense you get with operator ++ on floats; a++ is not 
necessarily different to a. I would hope that this feature never actually gets 
used. Does this compile?

enum : cfloat { A=2, B, C }

The important point is that you are now trying to minimise the effect of the 
special case which has been created. But there's no way to get rid of it, 
because it is fundamental to the nature of enums.
AFAICT there's also special cases related to the grouping (named vs unnamed 
enums) and with regard to the typing (name mangling).