It would also be useful (for some code I have) to be able to define a certain subset of integers that *could* be implicitly cast to the enum type.  Specifically, 0 is a special case for many functions that take enums as parameters, and IMHO '0' is a better identifier than "ENUM_TYPE_DEFAULT".

    enum foo {
        0,                    // a constant 0 can be implicitly cast to foo
        RUNNING,      // defined to be 1
        IDLE                // defined to be 2
    }

Maybe this is too crazy...I could just defined DEFAULT=0.

--
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))) ]

"Walter" <walter@digitalmars.com> wrote in message news:a4jfd4$1rar$2@digitaldaemon.com...

> > 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>.

Still... why not an override attribute for import directive?

    import foo, bar;      // normal import: any conflicts have to be
                          // disambiguated explicitly

    override import baz;  // all identifiers in baz override those in
                          // foo and bar with the same name

Identifiers could also be overriden twice or more:

    import foo;            // contains Foo
    override import bar;   // contains Foo; overrides foo.Foo
    override import baz;   // contains Foo; overrides bar.Foo

Whaddya think?

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C6D637D.6C18BF32@deming-os.org...

> It would also be useful (for some code I have) to be able to define a certain subset of integers that *could* be implicitly cast to the enum type.  Specifically, 0 is a special case for many functions that take
enums
> as parameters, and IMHO '0' is a better identifier than
"ENUM_TYPE_DEFAULT".
>
>     enum foo {
>         0,                    // a constant 0 can be implicitly cast to
foo
>         RUNNING,      // defined to be 1
>         IDLE                // defined to be 2
>     }

Then maybe it's better for "null" to be implicitly castable to any enum type?

Pavel Minayev wrote:

> Still... why not an override attribute for import directive?
>
>     import foo, bar;      // normal import: any conflicts have to be
>                           // disambiguated explicitly
>
>     override import baz;  // all identifiers in baz override those in
>                           // foo and bar with the same name
>
> Identifiers could also be overriden twice or more:
>
>     import foo;            // contains Foo
>     override import bar;   // contains Foo; overrides foo.Foo
>     override import baz;   // contains Foo; overrides bar.Foo
>
> Whaddya think?

For the stuff I'm talking about, that would be far WORSE than anything else. What if foo (which you wrote lots of code for) defined SUCCESS as 1, while bar or baz defined it as 0?  Then all your "return SUCCESS" would actually be doing "return FAIL".  I'd prefer the ambiguity :(

--
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))) ]

Good idea!  Any other viewpoints?

--
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:3C6D6E43.F7626219@deming-os.org...

> For the stuff I'm talking about, that would be far WORSE than anything
else.
> What if foo (which you wrote lots of code for) defined SUCCESS as 1, while
bar
> or baz defined it as 0?  Then all your "return SUCCESS" would actually be
doing
> "return FAIL".  I'd prefer the ambiguity :(

For this reason, named enums should be used:

    enum Foo { Success, Failure }
    enum Bar { Failure, Success }
    ...
    foo = Foo.Success;
    bar = Bar.Success;

The generic idea of one modules overriding other is better applied to functions and classes, and was discussed earlier... I just thought I'd raise the point once again =)

Oh, BTW, Walter, what about private imports?

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C6D6E57.B365408B@deming-os.org...

> Good idea!  Any other viewpoints?

Yes, one =)

    enum Foo { whatever, Running, Idle }
    ...
    foo = Foo.min;

min is a standard property for any enum... it's not always 0 so you have to ensure that minimal member is zero.

Also, using null for enums might be not a good idea (since it's already used with pointers). What about "default"?

    // default can be a separate member...
    enum Foo { default = 0, Running, Idle }
    ...
    Foo foo;
    foo = default;

    // .. or one of existing members can be default
    enum Bar { default Running = 0, Idle }
    ...
    Bar bar
    bar = default;    // could be Bar.Running

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C6C3AC0.4F438635@deming-os.org...
> Two suggestions:
.....
> 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
>     }

YES!  Although bitfields can accomplish about the same thing as flags, and can be cleaner, although they rely heavily on the compiler to optimize them back to flags.

Also if this flag thing is introduced, the type defined by it should accept any union of the individual flag members, such as:

flag Colors
{
  RED,BLUE,GREEN,
}

Colors acolor = RED|GREEN;   // NO CAST NEEDED -- result of OR'ing two
members of
                                                // flag Colors is another
value of type Colors, NOT an int.

Sean

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a4ktv4$2fbs$1@digitaldaemon.com...

> YES!  Although bitfields can accomplish about the same thing as flags, and can be cleaner, although they rely heavily on the compiler to optimize
them
> back to flags.

Especially since D has no bitfields =)
Only arrays of bits, which is not the same...

> Also if this flag thing is introduced, the type defined by it should
accept
> any union of the individual flag members, such as:
>
> flag Colors
> {
>   RED,BLUE,GREEN,
> }
>
> Colors acolor = RED|GREEN;   // NO CAST NEEDED -- result of OR'ing two
> members of
>                                                 // flag Colors is another
> value of type Colors, NOT an int.

I propose to use operator + for this purpose. It makes more clear that colors are Red AND (PLUS) Green. Also, to disambiguate the declarations, you would either use the qualifier:

    color = Color.RED + Color.GREEN;

...or a "flags constructor":

    color = Color[RED, GREEN];

Pavel Minayev wrote:
> "Sean L. Palmer" <spalmer@iname.com> wrote in message
> news:a4ktv4$2fbs$1@digitaldaemon.com...
> 
>>Also if this flag thing is introduced, the type defined by it should
>>accept any union of the individual flag members, such as:
>>
>>flag Colors
>>{
>>  RED,BLUE,GREEN,
>>}
>>
>>Colors acolor = RED|GREEN;   // NO CAST NEEDED -- result of OR'ing two
>>members of
>>                                                // flag Colors is another
>>value of type Colors, NOT an int.

YES!

> I propose to use operator + for this purpose. It makes more clear
> that colors are Red AND (PLUS) Green. 

I'd prefer that both | and + be available, and retain the
distinct meanings they have for ints. In the colors example,
if MAGENTA is defined as either RED+BLUE or RED|BLUE, there's
a useful semantic difference between MAGENTA+BLUE and
MAGENTA|BLUE (especially when you get away from constants
and into variables). Generations of us filthy unwashed C
fanatics have learned this weird distinction, and IMO it
would be Evil and Rude to suddenly make + do a bitwise OR.

You and your project team, of course, Pavel, are more than
welcome to define a "class Color" which overloads the plus
sign to do a bitwise OR. Or perhaps a bitwise AND. Whatever.

-RB