Another issue to consider is multi-bit values versus unique values.

In C enums are implemented as unique values, but D appears to take the
opposite approach.  Obviously, multi-bit values requires non-overlapping
values (vis. the enum(2) recommendation).

Perhaps enum(2) should be enum(bitmap) [hash out the syntax later] which
indicates to the compiler two things:
  a) multiple values may be set simultaneously
  b) values should not overlap (ergo the enum(2) behavior, even if the
     values aren't uniquely specified).

enum state { Init, Open, Read, Close };
enum filemode(bitmask) { Read, Write, Truncate };

state = Init;
filemode = Read | Write;
fd = open("foo.txt", filemode);
state = Open;
...

-- 
________________________________________________________________________ Kevin Quick                  Surgient Networks               Project UDI kevin.quick@surgient.com      Austin,  Texas                      Editor +1 512 241 4801              www.surgient.com         www.projectudi.org

>
> > 3. Referencing the above sample... emax(blah) = 0x14 and emin(blah) = 0
so
> > you can find ranges without considering the names of the enumerations or defining the ever-present MaxVal in your enumerations.
>
> YES!
>
That's just like pascal - on any eum type, the low() and high() built-in
functions will resolve at compile time to the first & last elements
respectively. Also, the suc() and pred() fns will give you next & previous
elements, which makes for loops and while loops on enums fairly trivial.

Enums are useful in pascal, and sets of enums even more so, especially for option flags. Yes, they are implemented as bit masks, but that's a detail you don't have to worry about.

"D Man" <clockwork@austin.rr.com> wrote in message news:9liemf$s2r$1@digitaldaemon.com...
> I currently use many enumerated values in my code.  I find myself setting values for bit flags and other non-linear sets.  What do you think of
these
> ideas? (Syntax is for illustration only.)
>
> 1. Power of n enumerations or multipliers.  enum(2) { a, b c}; a = 1, b =
2,
> c = 4, etc.

You are only doing this because you want to use a set, but don't know about as you are used to coding in an inappropriately low-level syntax in C. Sure, when you want to talk to the OS, you have to be reasonabley language-neutral so bits are the thing to use, but maybe 90% of the flags might only be used inside your program.

Delphi/Object pascal has many kimitations, but you can do this:

type
 TOption = (caps, indent, bold, reverse);

type
  TOptionSet = set of TOption;

procedure Demo;
var
  myOptions1, myOptions2, myOptions3: TOptionSet;
begin
 myOptions1 := [caps, indent];
 myOptions2 := [bold, indent];
 myOptions3 := myOptions1 + myOptions2; // union of 2 sets

 if (indent in myOptions3) then // membership test
 begin
 ...
 end;

Sets are  implemented as bitmasks, but as a programmer you don't need to worry about that, it just is good.

"D Man" <clockwork@austin.rr.com> wrote in message news:9liemf$s2r$1@digitaldaemon.com...
> I currently use many enumerated values in my code.  I find myself setting values for bit flags and other non-linear sets.  What do you think of
these
> ideas? (Syntax is for illustration only.)
>
> 1. Power of n enumerations or multipliers.  enum(2) { a, b c}; a = 1, b =
2,
> c = 4, etc.

You are only doing this because you want to use a set, but don't know about as you are used to coding in an inappropriately low-level syntax in C. Sure, when you want to talk to the OS, you have to be reasonabley language-neutral so bits are the thing to use, but maybe 90% of the flags might only be used inside your program.

Delphi/Object pascal has many kimitations, but you can do this:

type
 TOption = (caps, indent, bold, reverse);

type
  TOptionSet = set of TOption;

procedure Demo;
var
  myOptions1, myOptions2, myOptions3: TOptionSet;
begin
 myOptions1 := [caps, indent];
 myOptions2 := [bold, indent];
 myOptions3 := myOptions1 + myOptions2; // union of 2 sets

 if (indent in myOptions3) then // membership test
 begin
 ...
 end;

Sets are  implemented as bitmasks, but as a programmer you don't need to worry about that, it just is good.

"> "D Man" <clockwork@austin.rr.com> wrote in message
> news:9liemf$s2r$1@digitaldaemon.com...
> > I currently use many enumerated values in my code.  I find myself
setting
> > values for bit flags and other non-linear sets.  What do you think of
> these
> > ideas? (Syntax is for illustration only.)
> >
> > 1. Power of n enumerations or multipliers.  enum(2) { a, b c}; a = 1, b
=
> 2,
> > c = 4, etc.

Since D supports bit arrays, bit flags may be more appropriate as a bit array, with an ordinary enum indexing it.


> > 2. Previous value plus n.  enum blah { a, b + 0xf, c, d, e + 0x3}; a =
0,
> b
> > = 0xf, c = 0x10, d = 0x11, e = 0x14.

Already supported as:

    enum blah { a, b=a+0xf,c,d,e=d+3 }

> > 3. Referencing the above sample... emax(blah) = 0x14 and emin(blah) = 0
so
> > you can find ranges without considering the names of the enumerations or defining the ever-present MaxVal in your enumerations.

Done as blah.min and blah.max.

> > 4. Continuation of enumerations.  class A{ enum mode {input, output}; };
> > Class B: public A{ enum(append) mode {io, null }; };.  Useful if you add
> > modes via inheritance (ie, io class -- which uses multiple inheritence,
> > btw).  Using this would allow you to add new modes without all the
> > dependencies on initial statement.
> > 5. Access enumerations as arrays.  Using #4, mode[3] in the appended
> > enumeration yields the value for "io."  mode[3] in the un-appended
version
> > throws an exception.  You could remove values as well.
> > 6. As text.  So, using #4 again, as_text(mode[0]) returns a char * to
the
> > string "input".

These are interesting ideas.

"Walter" <walter@digitalmars.com> wrote in message news:a02q8n$hrt$1@digitaldaemon.com...

> Since D supports bit arrays, bit flags may be more appropriate as a bit array, with an ordinary enum indexing it.

Still... compare the following snippets

    enum { toread = 1, towrite = 2 }
    void open(char[] filename, uint mode);
    open("blah.blah", toread | towrite);

with:

    enum { toread, towrite }
    void open(char[] filename, bit[2] mode);
    open("blah.blah", [ toread: true, towrite: true ]);

I would personally prefer the first. On other hand, it would be nice to have some special initializer for bit arrays - so that we list the bits that should be turned on, and others are set to zero, just like with bit flags.

> > > 5. Access enumerations as arrays.  Using #4, mode[3] in the appended enumeration yields the value for "io."  mode[3] in the un-appended
> version
> > > throws an exception.  You could remove values as well.

Interesting.

> > > 6. As text.  So, using #4 again, as_text(mode[0]) returns a char * to
> the
> > > string "input".

Maybe as toString() method then? Could be of great use for I/O library, to print enums as readable strings rather than numbers...

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a02quf$i71$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a02q8n$hrt$1@digitaldaemon.com...
>
> > Since D supports bit arrays, bit flags may be more appropriate as a bit array, with an ordinary enum indexing it.
>
> Still... compare the following snippets
>
>     enum { toread = 1, towrite = 2 }
>     void open(char[] filename, uint mode);
>     open("blah.blah", toread | towrite);
>
> with:
>
>     enum { toread, towrite }
>     void open(char[] filename, bit[2] mode);
>     open("blah.blah", [ toread: true, towrite: true ]);
>
> I would personally prefer the first.

You can still do the first in D.

> On other hand, it would
> be nice to have some special initializer for bit arrays - so
> that we list the bits that should be turned on, and others
> are set to zero, just like with bit flags.

What's wrong with [toread:true, towrite:true]?

"Walter" <walter@digitalmars.com> wrote in message news:a032at$me1$1@digitaldaemon.com...

> You can still do the first in D.

I know because I use it that way =)

> What's wrong with [toread:true, towrite:true]?

Nothing. But it'd be great if there were some
kind of syntactic sugar for that, maybe like
this?

    [[toread, towrite]]