PhobosWatch: manifest => enum

[Bruce Adams]

On Sun, 30 Dec 2007 01:47:03 -0000, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Bruce Adams wrote:
>> Personally I always name my types but there may be those that don't.
>> Is this currently illegal then?
>>  class Colour
>> {
>> private:
>>   // private helper type defining colour state variable
>>   // using an anonymous enum.
>>   enum { red, green, blue } colour;
>> };
>
> Yes, it is illegal.
>
No problem there then.

>> Why opAdd and not opIncrement?
>
> opIncrement is redundant, as it's a subset of opAdd.
>
>> opAdd(int) seems unnatural for user defined types. They would have to  
>> ignore the
>> argument and it would lead to some odd bugs and confusions.
>
> I don't know why it would be unnatural. To me, a type that can be  
> incremented but not added would seem very strange indeed.
>
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.

Granted you can use a sucessor operation to define addition that's the  
typical way number theory
is derived from set theory but we are talking about programmers who can  
make errors.

enum Colour { red, green, blue, indigo }

Colour c = red;
c++; // c = blue

Colour c2 = red+green; //a bad thing to allow.


>
>> Very contrived and poorly chosen example:
>>  class Foo
>> {
>> public:
>>   // helper type
>>   enum FooType
>>   {
>>     A = "foo",
>>     B = "bar",
>>     C = "snafu"
>>   }
>> private:
>>   // state - bar may be one o
>>   string Bar;
>>  public:
>>   Foo()
>>   {
>>     Bar = A;
>>   }
>>    // only used to allow creation of Foo based enums.
>>   Foo opAdd(int)
>>   {
>>     Bar++;
>
> A string cannot be incremented.
>
I said it was poorly chosen :-). All I'm saying is a programmer might be  
tempted to
defined opAdd with the semantics of an increment operation if they only  
wanted
this behaviour at all to allow them to define enumerations with a  
different successor
operation.
Here is another less poor but still non-optimal example.

class OddNumbers
{
    // helper type
    typedef int FooType;

    // state
    FooType bar;

    Foo()
    {
      bar = 1;
    }

    // bad semantics - hacked to value OddEnum as required.
    Foo opAdd(int)
    {
      bar += 2;
    }
}

enum OddEnum: OddNumbers
{
   one = 1,
   three,  // == 3
   five  // == 5
}


This is not a brilliant example as it is sensible to have a genuine  
addition operator
for odd numbers but for many types you could be defining opAdd(int) for  
this purpose
when int is not sensibly addable to the class itself.