Two suggestions:

1) Allow multiple enums with the same name; determine which is
appropriate based on context (what they are being used for):
    enum {  SUCCESS, FAIL } foo;  // SUCCESS=0, FAIL=1
    enum {  FAIL, SUCCESS } bar;  // FAIL=0,SUCCESS=1
    foo f = SUCCESS;
    bar b = SUCCESS;
    int i = f;    // i = 0
    int j = b;    // i = 1
I know it's not C-like...but it means that you can mix libraries with
similar declarations with no problems.  Otherwise SUCCESS has to be
defined as MYAPI_SUCCESS to ensure that there's no conflict.

2) Allow a new keyword, 'flags' that is exactly like an enum except that
the default assigned values are bitflags.  The default first value is
0x01; the next assigned flag is found by taking the first unused bit:
    flag {
        RED,        // 0x01
        BLUE,        // 0x02
        RED_BLUE = RED | BLUE,    // 0x03
        GREEN,        // 0x04  (this is the first unused bit)
        BLACK = 0,    // 0x00
        WHITE = ~BLACK
    }

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C6C3AC0.4F438635@deming-os.org...
> Two suggestions:
>
> 1) Allow multiple enums with the same name; determine which is
> appropriate based on context (what they are being used for):
>     enum {  SUCCESS, FAIL } foo;  // SUCCESS=0, FAIL=1
>     enum {  FAIL, SUCCESS } bar;  // FAIL=0,SUCCESS=1
>     foo f = SUCCESS;
>     bar b = SUCCESS;
>     int i = f;    // i = 0
>     int j = b;    // i = 1
> I know it's not C-like...but it means that you can mix libraries with
> similar declarations with no problems.  Otherwise SUCCESS has to be
> defined as MYAPI_SUCCESS to ensure that there's no conflict.

With the import module system, whenever there's an ambiguity, it can be
resolved by prefixing the name with the module name, like:
    myabi.SUCCESS

> 2) Allow a new keyword, 'flags' that is exactly like an enum except that
> the default assigned values are bitflags.  The default first value is
> 0x01; the next assigned flag is found by taking the first unused bit:
>     flag {
>         RED,        // 0x01
>         BLUE,        // 0x02
>         RED_BLUE = RED | BLUE,    // 0x03
>         GREEN,        // 0x04  (this is the first unused bit)
>         BLACK = 0,    // 0x00
>         WHITE = ~BLACK
>     }

You can use:
    enum flag {
         RED = 0x01,
         BLUE = 0x02,
         RED_BLUE = RED | BLUE,
         GREEN = 0x04, // (this is the first unused bit)
         BLACK = 0,
        WHITE = ~BLACK,
    }

now.

Walter wrote:
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> news:3C6C3AC0.4F438635@deming-os.org...
>>2) Allow a new keyword, 'flags' that is exactly like an enum except that
>>the default assigned values are bitflags.  The default first value is
>>0x01; the next assigned flag is found by taking the first unused bit:
>>    flag {
>>        RED,        // 0x01
>>        BLUE,        // 0x02
>>        RED_BLUE = RED | BLUE,    // 0x03
>>        GREEN,        // 0x04  (this is the first unused bit)
>>        BLACK = 0,    // 0x00
>>        WHITE = ~BLACK
>>    }
>>
> 
> You can use:
>     enum flag {
>          RED = 0x01,
>          BLUE = 0x02,
>          RED_BLUE = RED | BLUE,
>          GREEN = 0x04, // (this is the first unused bit)
>          BLACK = 0,
>         WHITE = ~BLACK,
>     }
> 
> now.

Yup, and when you start adding new elements with careless
cut-n-paste when you're short of sleep, you wind up with
two different flags using the 0x200 bit and then bad things
happen and you cry. The automatic bit-using behavior that
Russ Lewis suggests would avoid that problem neatly.

You can just tell us to get more sleep, of course....

-RB

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C6C3AC0.4F438635@deming-os.org...
> Two suggestions:
>
> 1) Allow multiple enums with the same name; determine which is
> appropriate based on context (what they are being used for):
>     enum {  SUCCESS, FAIL } foo;  // SUCCESS=0, FAIL=1
>     enum {  FAIL, SUCCESS } bar;  // FAIL=0,SUCCESS=1
>     foo f = SUCCESS;
>     bar b = SUCCESS;
>     int i = f;    // i = 0
>     int j = b;    // i = 1
> I know it's not C-like...but it means that you can mix libraries with
> similar declarations with no problems.  Otherwise SUCCESS has to be
> defined as MYAPI_SUCCESS to ensure that there's no conflict.

You forget about the fact that each named enum has its own namespace. So your example should look like this in D (also note the difference in syntax =)):

    enum foo { SUCCESS, FAIL }
    enum bar { FAIL, SUCCESS }
    foo f = foo.SUCCESS;
    bar b = bar.SUCCESS;
    ...

So it is impossible to get a name clash. This also makes it unnecessary to prefix enum members with some kind of "enum namespace tag":

    enum Border
    {
        None,
        Single,
        Sizeable,
        Dialog,
        ToolWin,
        SizeToolWin
    }

Even if you get a variable named Single, the name clash still doesn't happen. A cool feature I must say!

> 2) Allow a new keyword, 'flags' that is exactly like an enum except that
> the default assigned values are bitflags.  The default first value is
> 0x01; the next assigned flag is found by taking the first unused bit:
>     flag {
>         RED,        // 0x01
>         BLUE,        // 0x02
>         RED_BLUE = RED | BLUE,    // 0x03
>         GREEN,        // 0x04  (this is the first unused bit)
>         BLACK = 0,    // 0x00
>         WHITE = ~BLACK
>     }

This is a good idea, IMO. Great when you have something like 20 flags, and it's soooo easy to make a mistake while typing, say mistype 0x80 for 0x90, and then you can't understand why your program doesn't work...

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C6C7043.3060402@estarcion.com...

> You can just tell us to get more sleep, of course....

... but the appropriate features (to help the programmer to sleep for at least 8 hours) should be added to D then...

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a4i4ge$1826$1@digitaldaemon.com...

> You forget about the fact that each named enum has its own namespace. So your example should look like this in D (also note the difference in syntax =)):
>
>     enum foo { SUCCESS, FAIL }
>     enum bar { FAIL, SUCCESS }
>     foo f = foo.SUCCESS;
>     bar b = bar.SUCCESS;
>     ...
>
> So it is impossible to get a name clash.

   Is this so? Is there no way to use it without the prefix?

> A cool feature I must say!

   I'm not sure I like it.

> > 2) Allow a new keyword, 'flags' that is exactly like an enum except that
> > the default assigned values are bitflags.  The default first value is
> > 0x01; the next assigned flag is found by taking the first unused bit:
> >     flag {
> >         RED,        // 0x01
> >         BLUE,        // 0x02
> >         RED_BLUE = RED | BLUE,    // 0x03
> >         GREEN,        // 0x04  (this is the first unused bit)
> >         BLACK = 0,    // 0x00
> >         WHITE = ~BLACK
> >     }
>
> This is a good idea, IMO. Great when you have something like 20 flags, and it's soooo easy to make a mistake while typing, say mistype 0x80 for 0x90, and then you can't understand why your program doesn't work...

   Not only that. I don't know what D does, but in C++, if you want to
combine bits from an enum and assign it to a variable of the enum type, you
need to do an explicit cast. For example:

enum Speech {
  Blah,   // 0x01
  Yadda,  // 0x02
  Mumble, // 0x04
};

Speech mySpeech1 = Blah | Yadda; // Doesn't work!
Speech mySpeech2 = Speech(Blah | Yadda); // Works

Salutaciones,
                   JCAB
http://www.JCABs-Rumblings.com

"Juan Carlos Arevalo Baeza" <jcab@JCABs-Rumblings.com> wrote in message news:a4i7lv$19dn$1@digitaldaemon.com...

>    Is this so? Is there no way to use it without the prefix?

Yes. But you can use something like:

    enum { red, green, blue }
    alias int Color;

>    Not only that. I don't know what D does, but in C++, if you want to
> combine bits from an enum and assign it to a variable of the enum type,
you
> need to do an explicit cast. For example:
>
> enum Speech {
>   Blah,   // 0x01
>   Yadda,  // 0x02
>   Mumble, // 0x04
> };
>
> Speech mySpeech1 = Blah | Yadda; // Doesn't work!
> Speech mySpeech2 = Speech(Blah | Yadda); // Works

It is so in D as well. So, the flags construct should support this... know what it reminds me of? Pascal set-types! It'd be great to have these in D:

    set Speech { Blah, Yadda, Mumble }
    ...
    Speech speech;
    speech = Speech[Blah, Yadda];
    ...
    if (speech.Blah)
    {
        speech += Speech.Mumble;
        speech -= Speech.Blah;
    }
    ...
    speech -= Speech[Yadda, Mumble];

Well you get the idea. Internally the set is represented
by an int bitfield. You can initialize it, add or remove
(or set and reset in other interpretation) elements, add,
subtract and multiply sets:

    set Color { Red, Green, Blue }
    ...
    foo = Color[Red, Green];
    bar = Color[Green, Blue];
    ...
    baz = foo + bar;    // baz is now Color[Red, Green, Blue]
    baz = foo - bar;    // baz is now Color[Red]
    baz = foo * bar;    // baz is now Color[Green]

Walter wrote:

> With the import module system, whenever there's an ambiguity, it can be
> resolved by prefixing the name with the module name, like:
>     myabi.SUCCESS

Right!  This is a Good Thing, and is a substantial upgrade over C++.

However, my primary desire was not to be able to resolve ambiguities, but to reduce unnecessary typing.  I would prefer that the user not even have to consider dealing with ambiguities when context could resolve them.

This is especially true if you were using just one of the modules...and had typed all your code using "SUCCESS".  Then you add an import to your code, and suddenly you have "ambiguous symbol" popping up all over your code.  That would make me frown, to have to do a search & replace all over my code..

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C6D2C25.71BE05C2@deming-os.org...
> However, my primary desire was not to be able to resolve ambiguities, but
to
> reduce unnecessary typing.  I would prefer that the user not even have to consider dealing with ambiguities when context could resolve them.

In most cases, there won't be any ambiguity, and you won't need to put the module qualifier on.

> This is especially true if you were using just one of the modules...and
had
> typed all your code using "SUCCESS".  Then you add an import to your code,
and
> suddenly you have "ambiguous symbol" popping up all over your code.  That would make me frown, to have to do a search & replace all over my code..

It's not that bad <g>.

Pavel Minayev wrote:
> "Russell Borogove" <kaleja@estarcion.com> wrote in message
> news:3C6C7043.3060402@estarcion.com...
> 
> 
>>You can just tell us to get more sleep, of course....
>>
> 
> ... but the appropriate features (to help the programmer to sleep
> for at least 8 hours) should be added to D then...

Right -- and to get that kind of sleep, we need fewer errors
in our code and more peace of mind, so either way the "flags"
version of enum should be available.

-RB