PhobosWatch: manifest => enum

Bruce Adams tortoise_74 at yeah.who.co.uk
Sat Dec 29 20:15:44 PST 2007


On Sun, 30 Dec 2007 03:41:40 -0000, Janice Caron <caron800 at googlemail.com>  
wrote:

> On 12/30/07, Bruce Adams <tortoise_74 at yeah.who.co.uk> wrote:
>> Surely that is what we mean with an enumeration. We allow successor (and
>> optionally predecessor)
>> operations to cycle through the entities in a particular order but  
>> adding
>> them is unnatural.
>
> In a true enumeration, it isn't that unreasonable to equate ++ or +1
> with the successor function, and -- or -1 with the predecessor
> function.
>
> Given that, for an enum type E, what you want to allow is
>
>     E opAdd(int)
>     E opSub(int)
>
> but you want to disallow
>
>     E opAdd(E)
>     E opSub(E)
>
> So to use your example:
>
>     Colour c2 = red+green; //WRONG
>     Colour c2 = red+2; //OK
>
> the latter meaning the successor of the successor. Of course D enums
> aren't true enums, so we might end up having to allow "red+green" by
> accident. :-)

Which is a bad thing.
I would also like the option to prevent red+2 at compile time.
Its not going to be terribly helpful to pick up an out of range error if
someone foolishly adds an integer that takes the value out of the permitted
range for the type. enumeraitons are not closed under addition. Okay fixed  
length
binary integers aren't either but they are less closed and have well  
defined if
often undesireable overflow semantics.



More information about the Digitalmars-d mailing list