It doesn't seem that I can access enum members without qualifying them.

enum colors { red=0, green=1, blue=2 };

int whichcolor = red; // error unknown identifier
int whichcolor = colors.red; // ok

This is causing grief when porting direct3d apps which expect their enum members to be globally accessible.  I'd change them to const int etc but they really are an enum and I'd lose typechecking capability. I suppose I could write it like so:

typedef uint D3DRENDERSTATETYPE;
const D3DRENDERSTATETYPE D3DRS_ALPHABLENDENABLE = 196;
//etc

But I'd rather that enum just worked as expected.

Sean

You won't need to qualify them if you make them anonymous enums, like:
    enum { red, green, blue }

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:adtnqu$16j2$1@digitaldaemon.com...
> It doesn't seem that I can access enum members without qualifying them.
>
> enum colors { red=0, green=1, blue=2 };
>
> int whichcolor = red; // error unknown identifier
> int whichcolor = colors.red; // ok
>
> This is causing grief when porting direct3d apps which expect their enum members to be globally accessible.  I'd change them to const int etc but they really are an enum and I'd lose typechecking capability. I suppose I could write it like so:
>
> typedef uint D3DRENDERSTATETYPE;
> const D3DRENDERSTATETYPE D3DRS_ALPHABLENDENABLE = 196;
> //etc
>
> But I'd rather that enum just worked as expected.
>
> Sean
>
>

Yuch!

Surely it is better to enforce the qualification. Maintenance costs far exceed original authoring, so who cares about a little effort now?

"Walter" <walter@digitalmars.com> wrote in message news:adtsm9$1b4s$1@digitaldaemon.com...
> You won't need to qualify them if you make them anonymous enums, like:
>     enum { red, green, blue }
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:adtnqu$16j2$1@digitaldaemon.com...
> > It doesn't seem that I can access enum members without qualifying them.
> >
> > enum colors { red=0, green=1, blue=2 };
> >
> > int whichcolor = red; // error unknown identifier
> > int whichcolor = colors.red; // ok
> >
> > This is causing grief when porting direct3d apps which expect their enum members to be globally accessible.  I'd change them to const int etc but they really are an enum and I'd lose typechecking capability. I suppose
I
> > could write it like so:
> >
> > typedef uint D3DRENDERSTATETYPE;
> > const D3DRENDERSTATETYPE D3DRS_ALPHABLENDENABLE = 196;
> > file://etc
> >
> > But I'd rather that enum just worked as expected.
> >
> > Sean
> >
> >
>
>

We don't want ADA-style mandates, do we?  If there's a conflict, sure, but if no conflict why inflict such pain on the programmer?

If you strictly compartmentalize everything  and enforce scope qualifications for everything, D would end up being a quite wordy language.

Sean

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:adu2pt$1gtv$2@digitaldaemon.com...
> Yuch!
>
> Surely it is better to enforce the qualification. Maintenance costs far exceed original authoring, so who cares about a little effort now?
>
> "Walter" <walter@digitalmars.com> wrote in message news:adtsm9$1b4s$1@digitaldaemon.com...
> > You won't need to qualify them if you make them anonymous enums, like:
> >     enum { red, green, blue }
> >
> > "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:adtnqu$16j2$1@digitaldaemon.com...
> > > It doesn't seem that I can access enum members without qualifying
them.
> > >
> > > enum colors { red=0, green=1, blue=2 };
> > >
> > > int whichcolor = red; // error unknown identifier
> > > int whichcolor = colors.red; // ok
> > >
> > > This is causing grief when porting direct3d apps which expect their
enum
> > > members to be globally accessible.  I'd change them to const int etc
but
> > > they really are an enum and I'd lose typechecking capability. I
suppose
> I
> > > could write it like so:
> > >
> > > typedef uint D3DRENDERSTATETYPE;
> > > const D3DRENDERSTATETYPE D3DRS_ALPHABLENDENABLE = 196;
> > > file://etc
> > >
> > > But I'd rather that enum just worked as expected.
> > >
> > > Sean
> > >
> > >
> >
> >
>
>

How would you qualify an unnamed enum <g>?

In any case, I've found anonymous enums to be handy when converting existing C code over.

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:adu2pt$1gtv$2@digitaldaemon.com...
> Yuch!
>
> Surely it is better to enforce the qualification. Maintenance costs far exceed original authoring, so who cares about a little effort now?
>
> "Walter" <walter@digitalmars.com> wrote in message news:adtsm9$1b4s$1@digitaldaemon.com...
> > You won't need to qualify them if you make them anonymous enums, like:
> >     enum { red, green, blue }

What I want is an anonymous enum with a name, evidently.  ;)

Sean

"Walter" <walter@digitalmars.com> wrote in message news:adu3d5$1hfa$1@digitaldaemon.com...
> How would you qualify an unnamed enum <g>?
>
> In any case, I've found anonymous enums to be handy when converting
existing
> C code over.
>
> "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:adu2pt$1gtv$2@digitaldaemon.com...
> > Yuch!
> >
> > Surely it is better to enforce the qualification. Maintenance costs far exceed original authoring, so who cares about a little effort now?
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:adtsm9$1b4s$1@digitaldaemon.com...
> > > You won't need to qualify them if you make them anonymous enums, like:
> > >     enum { red, green, blue }

Sure. I'm not advocating that we end up with Java's ridiculously low functionality : SLOCs ratio, but there are certain issues that seem pretty cut and dried (I'm just putting up my umbrella in anticipation of you all raining down scorn upon me) such as:

1. Mandatory braces. Almost all experienced programmers end up putting them
in everywhere, so let's just admit that the odd bit of typing now will save
masses of effort later. IDE macros can easily be made to do this for us
anyway, for those who dislike key-presses.
2. Conditional expressions must be boolean. Thus one must compare integrals
against constant

    int    i;

    ...

    if(i != 0)

and pointers (sorry, I mean references, spot the C++ programmer!) must
compare to null

    SomeObject    o

    ...

    if(o != null)

This is not going to affect generated code in anyway, but is (i) more
immediately accessible to the reviewer/maintainer (not to mention the
original author some months later), and (ii) less error-prone

I believe there is a precedent for this kind of rigour (unless memory misserves) in Walter's requiring all enum members to be mentioned in switch statements (of enums) as a guard against addition to the enum without addition to the switch case list. (Can someone refresh my memory as to the exact nature of this post?)



"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:adu3ar$1he8$1@digitaldaemon.com...
> We don't want ADA-style mandates, do we?  If there's a conflict, sure, but if no conflict why inflict such pain on the programmer?
>
> If you strictly compartmentalize everything  and enforce scope qualifications for everything, D would end up being a quite wordy
language.
>
> Sean
>
> "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:adu2pt$1gtv$2@digitaldaemon.com...
> > Yuch!
> >
> > Surely it is better to enforce the qualification. Maintenance costs far exceed original authoring, so who cares about a little effort now?
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:adtsm9$1b4s$1@digitaldaemon.com...
> > > You won't need to qualify them if you make them anonymous enums, like:
> > >     enum { red, green, blue }
> > >
> > > "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:adtnqu$16j2$1@digitaldaemon.com...
> > > > It doesn't seem that I can access enum members without qualifying
> them.
> > > >
> > > > enum colors { red=0, green=1, blue=2 };
> > > >
> > > > int whichcolor = red; // error unknown identifier
> > > > int whichcolor = colors.red; // ok
> > > >
> > > > This is causing grief when porting direct3d apps which expect their
> enum
> > > > members to be globally accessible.  I'd change them to const int etc
> but
> > > > they really are an enum and I'd lose typechecking capability. I
> suppose
> > I
> > > > could write it like so:
> > > >
> > > > typedef uint D3DRENDERSTATETYPE;
> > > > const D3DRENDERSTATETYPE D3DRS_ALPHABLENDENABLE = 196;
> > > > file://etc
> > > >
> > > > But I'd rather that enum just worked as expected.
> > > >
> > > > Sean
> > > >
> > > >
> > >
> > >
> >
> >
>
>

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:adu3qg$1hsh$1@digitaldaemon.com...

> What I want is an anonymous enum with a name, evidently.  ;)

Just make an alias:

    alias int OLD_C_ENUM;
    enum { ... }

This worked fine for me. =)

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:adu4u3$1j4h$1@digitaldaemon.com...

> 1. Mandatory braces. Almost all experienced programmers end up putting
them
> in everywhere, so let's just admit that the odd bit of typing now will
save
> masses of effort later. IDE macros can easily be made to do this for us anyway, for those who dislike key-presses.

For more flame on this topic, you might want to post this into the thread started earlier for the same reason. =)

> 2. Conditional expressions must be boolean. Thus one must compare
integrals
> against constant
>
> This is not going to affect generated code in anyway, but is (i) more
> immediately accessible to the reviewer/maintainer (not to mention the
> original author some months later), and (ii) less error-prone

You know, I myself find this feature quite convenient, both when I write programs and when I read others code. Clearly, !a is the same as (a != 0).

One thing that caused problem was when you wrote "if (a = 1)", but
it is forbidden in D now.

And a very good thing too. Now if we can wean all the terse programmers away from all their other write-once unmaintain-ever-more practises, we should really be cooking

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ae34ps$leg$1@digitaldaemon.com...
> "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:adu4u3$1j4h$1@digitaldaemon.com...
>
> > 1. Mandatory braces. Almost all experienced programmers end up putting
> them
> > in everywhere, so let's just admit that the odd bit of typing now will
> save
> > masses of effort later. IDE macros can easily be made to do this for us anyway, for those who dislike key-presses.
>
> For more flame on this topic, you might want to post this into the thread started earlier for the same reason. =)
>
> > 2. Conditional expressions must be boolean. Thus one must compare
> integrals
> > against constant
> >
> > This is not going to affect generated code in anyway, but is (i) more
> > immediately accessible to the reviewer/maintainer (not to mention the
> > original author some months later), and (ii) less error-prone
>
> You know, I myself find this feature quite convenient, both when I write programs and when I read others code. Clearly, !a is the same as (a != 0).
>
> One thing that caused problem was when you wrote "if (a = 1)", but
> it is forbidden in D now.
>
>
>