Walter,

I read on DigitalMars' website, under the "Arrays that parallel an enum" paragraph in the "Converting C to D" section ( http://www.digitalmars.com/d/ctod.html#arrayenum ) that Walter defines the D way of declaring such an array "not perfect, but better" with respect to the C (no-) way. Maybe suggestions on this have already been given, but how about something like:

enum COLORS { red, blue, green }
char cstring[COLORS][] = [red: "red", blue: "blue", green: "green"];

In other words, take an enum type name as synonim for its range wherever a range is expected or allowed, then (here pardon my ignorance about compiler theory) make the enum a default namespace with regard to the array index. I know it looks a lot like Delphi... as a matter of fact, a *lot* of D already does. Just add bitfields, subrange types and Pascal-like sets to D, and it's the language of my wildest dreams (er, my wildest *programming* dreams ;-) ), that is, more concise than C/C++, as formal as Delphi (I intentionally don't mention "plain" Pascal which is even too formal for real-world use) and even more fun than Basic to use.

Anyway, regardless of your decisions about subranges and sets, D really ROCKS! (In case you're wondering, yes, I'm one of those who set maximum warning level, warnings as errors, etc. etc.)

Bye & Thanks
Ric

That is a good idea. -Walter

"Riccardo De Agostini" <riccardo.de.agostini@email.it> wrote in message news:bg8p6j$1idv$1@digitaldaemon.com...
> Walter,
>
> I read on DigitalMars' website, under the "Arrays that parallel an enum" paragraph in the "Converting C to D" section ( http://www.digitalmars.com/d/ctod.html#arrayenum ) that Walter defines the
D
> way of declaring such an array "not perfect, but better" with respect to
the
> C (no-) way. Maybe suggestions on this have already been given, but how
> about something like:
>
> enum COLORS { red, blue, green }
> char cstring[COLORS][] = [red: "red", blue: "blue", green: "green"];
>
> In other words, take an enum type name as synonim for its range wherever a range is expected or allowed, then (here pardon my ignorance about
compiler
> theory) make the enum a default namespace with regard to the array index. I know it looks a lot like Delphi... as a matter of fact, a *lot* of D already does. Just add bitfields, subrange types and Pascal-like sets to
D,
> and it's the language of my wildest dreams (er, my wildest *programming* dreams ;-) ), that is, more concise than C/C++, as formal as Delphi (I intentionally don't mention "plain" Pascal which is even too formal for real-world use) and even more fun than Basic to use.
>
> Anyway, regardless of your decisions about subranges and sets, D really ROCKS! (In case you're wondering, yes, I'm one of those who set maximum warning level, warnings as errors, etc. etc.)
>
> Bye & Thanks
> Ric
>
>

There is an easier way, in my opinion than enums: the set. A 'set' could be a foundamental element of the language. A set could contain anything, not only integers. Of course, integers would be automatically enumerated. Its syntax could be:

<type> set <name> = { <comma separated list of values> }

For example:

//color enum
int set COLORS = {
    RED,
    GREEN,
    BLUE
}

//days
string set DAYS = {
    SUNDAY = "Sunday",
    MONDAY = "Monday",
    TUESDAY = "Tuesday"
}

//bitfield set
bit[2] set STATE = {
    STATE_GREEN,
    STATE_RED,
    STATE_YELLOW,
    STATE_CYAN
}

A set could have many static properties useful in run-time:

FIRST = first value
LAST = last value
operator [int] = access value by index
operator [string] = access value by name
COUNT = number of values
NAME[int]  = access each set member's name as a string

It would certainly be better than simple enums; more readable, strongly typed; it would be of user-defined size (so structs that map to binary formats would be easier to code); the run-time type static information would be useful to gui IDEs...there are many advantages to it.

"Walter" <walter@digitalmars.com> wrote in message news:bh67dt$25nl$1@digitaldaemon.com...
> That is a good idea. -Walter
>
> "Riccardo De Agostini" <riccardo.de.agostini@email.it> wrote in message news:bg8p6j$1idv$1@digitaldaemon.com...
> > Walter,
> >
> > I read on DigitalMars' website, under the "Arrays that parallel an enum" paragraph in the "Converting C to D" section ( http://www.digitalmars.com/d/ctod.html#arrayenum ) that Walter defines
the
> D
> > way of declaring such an array "not perfect, but better" with respect to
> the
> > C (no-) way. Maybe suggestions on this have already been given, but how
> > about something like:
> >
> > enum COLORS { red, blue, green }
> > char cstring[COLORS][] = [red: "red", blue: "blue", green: "green"];
> >
> > In other words, take an enum type name as synonim for its range wherever
a
> > range is expected or allowed, then (here pardon my ignorance about
> compiler
> > theory) make the enum a default namespace with regard to the array
index.
> > I know it looks a lot like Delphi... as a matter of fact, a *lot* of D already does. Just add bitfields, subrange types and Pascal-like sets to
> D,
> > and it's the language of my wildest dreams (er, my wildest *programming* dreams ;-) ), that is, more concise than C/C++, as formal as Delphi (I intentionally don't mention "plain" Pascal which is even too formal for real-world use) and even more fun than Basic to use.
> >
> > Anyway, regardless of your decisions about subranges and sets, D really ROCKS! (In case you're wondering, yes, I'm one of those who set maximum warning level, warnings as errors, etc. etc.)
> >
> > Bye & Thanks
> > Ric
> >
> >
>
>

I'd rather have set apply to any type, but not define the possible values at the set declaration.

Like so:

set(int) intset = { 0, 5, 7 }; // make a set that can hold any int, but for now holds only 0, 5, and 7

enum days { SUNDAY = "Sunday", MONDAY = "Monday", TUESDAY = "Tuesday" } set(days) daysset = { MONDAY };

range(int, 0, 7) threebitrange;
set(threebitrange) threebitset;
threebitset.insert(2);
threebitset.insert(5);
threebitset.erase(2);
// now holds just 5

There are various ways sets can be implemented, depending on whether the number of possible values is large or small.  It can be anything from a simple array to a red/black tree, or any number of other implementations. It should be up to the compiler and transparent to the user.

Yes you 'could' probably do this in a user-defined library, but you wouldn't get any syntax sugar from the language to make it easier to use, that way.

Sean

"Achilleas Margaritis" <axilmar@in.gr> wrote in message news:bh8473$11cp$1@digitaldaemon.com...
> There is an easier way, in my opinion than enums: the set. A 'set' could
be
> a foundamental element of the language. A set could contain anything, not only integers. Of course, integers would be automatically enumerated. Its syntax could be:
>
> <type> set <name> = { <comma separated list of values> }
>
> For example:
>
> //color enum
> int set COLORS = {
>     RED,
>     GREEN,
>     BLUE
> }
>
> //days
> string set DAYS = {
>     SUNDAY = "Sunday",
>     MONDAY = "Monday",
>     TUESDAY = "Tuesday"
> }
>
> //bitfield set
> bit[2] set STATE = {
>     STATE_GREEN,
>     STATE_RED,
>     STATE_YELLOW,
>     STATE_CYAN
> }
>
> A set could have many static properties useful in run-time:
>
> FIRST = first value
> LAST = last value
> operator [int] = access value by index
> operator [string] = access value by name
> COUNT = number of values
> NAME[int]  = access each set member's name as a string
>
> It would certainly be better than simple enums; more readable, strongly typed; it would be of user-defined size (so structs that map to binary formats would be easier to code); the run-time type static information
would
> be useful to gui IDEs...there are many advantages to it.
>
> "Walter" <walter@digitalmars.com> wrote in message news:bh67dt$25nl$1@digitaldaemon.com...
> > That is a good idea. -Walter
> >
> > "Riccardo De Agostini" <riccardo.de.agostini@email.it> wrote in message news:bg8p6j$1idv$1@digitaldaemon.com...
> > > Walter,
> > >
> > > I read on DigitalMars' website, under the "Arrays that parallel an
enum"
> > > paragraph in the "Converting C to D" section ( http://www.digitalmars.com/d/ctod.html#arrayenum ) that Walter defines
> the
> > D
> > > way of declaring such an array "not perfect, but better" with respect
to
> > the
> > > C (no-) way. Maybe suggestions on this have already been given, but
how
> > > about something like:
> > >
> > > enum COLORS { red, blue, green }
> > > char cstring[COLORS][] = [red: "red", blue: "blue", green: "green"];
> > >
> > > In other words, take an enum type name as synonim for its range
wherever
> a
> > > range is expected or allowed, then (here pardon my ignorance about
> > compiler
> > > theory) make the enum a default namespace with regard to the array
> index.
> > > I know it looks a lot like Delphi... as a matter of fact, a *lot* of D already does. Just add bitfields, subrange types and Pascal-like sets
to
> > D,
> > > and it's the language of my wildest dreams (er, my wildest
*programming*
> > > dreams ;-) ), that is, more concise than C/C++, as formal as Delphi (I
> > > intentionally don't mention "plain" Pascal which is even too formal
for
> > > real-world use) and even more fun than Basic to use.
> > >
> > > Anyway, regardless of your decisions about subranges and sets, D
really
> > > ROCKS! (In case you're wondering, yes, I'm one of those who set
maximum
> > > warning level, warnings as errors, etc. etc.)
> > >
> > > Bye & Thanks
> > > Ric
> > >
> > >
> >
> >
>
>

Another good/not so good thought, if enumerated types could support negative values with Riccardo's proposed format then any system error numbers could be directly mapped to error message strings making the support of system error messages in D very straight forward.

eg.

enum NETDB_ERROR_MSG : int
{
   NETDB_INTERNAL  = -1,
   NETDB_SUCCESS   =  0,
   HOST_NOT_FOUND  =  1,
   TRY_AGAIN       =  2,
   NO_RECOVERY     =  3,
}

char[NETDB_ERROR_MSG][] NETDB_ERROR =
[
   NETDB_INTERNAL: "NETDB_INTERNAL, See errno.",
   NETDB_SUCCESS: "NETDB_SUCCESS, No problem.",
   HOST_NOT_FOUND : "HOST_NOT_FOUND, Authoritative Answer Host ...",
   TRY_AGAIN : "TRY_AGAIN, Non-Authoritative Host not found or ...",
   NO_RECOVERY : "NO_RECOVERY, Non recoverable errors, FORMERR,..."
];

Final result: With this code no switch/if statements needed for any error generated from the system call!

HostSystemCall();
printf("Some error message header, %.*s", NETDB_ERROR[getHostErrno()]);



Any thoughts

Simon

Walter wrote:
> That is a good idea. -Walter

>>
>>enum COLORS { red, blue, green }
>>char cstring[COLORS][] = [red: "red", blue: "blue", green: "green"];
>>

> char[NETDB_ERROR_MSG][] NETDB_ERROR =
> [
>     NETDB_INTERNAL: "NETDB_INTERNAL, See errno.",
>     NETDB_SUCCESS: "NETDB_SUCCESS, No problem.",
>     HOST_NOT_FOUND : "HOST_NOT_FOUND, Authoritative Answer Host ...",
>     TRY_AGAIN : "TRY_AGAIN, Non-Authoritative Host not found or ...",
>     NO_RECOVERY : "NO_RECOVERY, Non recoverable errors, FORMERR,..."
> ];


Is this syntax (initalizing associatvie arrays ) in the new compiler ?

Charles


"Simon J Mackenzie" <project.d@smackoz.fastmail.fm> wrote in message news:bhvlaq$1ri7$1@digitaldaemon.com...
> Another good/not so good thought, if enumerated types could support negative values with Riccardo's proposed format then any system error numbers could be directly mapped to error message strings making the support of system error messages in D very straight forward.
>
> eg.
>
> enum NETDB_ERROR_MSG : int
> {
>     NETDB_INTERNAL  = -1,
>     NETDB_SUCCESS   =  0,
>     HOST_NOT_FOUND  =  1,
>     TRY_AGAIN       =  2,
>     NO_RECOVERY     =  3,
> }
>
> char[NETDB_ERROR_MSG][] NETDB_ERROR =
> [
>     NETDB_INTERNAL: "NETDB_INTERNAL, See errno.",
>     NETDB_SUCCESS: "NETDB_SUCCESS, No problem.",
>     HOST_NOT_FOUND : "HOST_NOT_FOUND, Authoritative Answer Host ...",
>     TRY_AGAIN : "TRY_AGAIN, Non-Authoritative Host not found or ...",
>     NO_RECOVERY : "NO_RECOVERY, Non recoverable errors, FORMERR,..."
> ];
>
> Final result: With this code no switch/if statements needed for any error generated from the system call!
>
> HostSystemCall();
> printf("Some error message header, %.*s", NETDB_ERROR[getHostErrno()]);
>
>
>
> Any thoughts
>
> Simon
>
> Walter wrote:
> > That is a good idea. -Walter
>
> >>
> >>enum COLORS { red, blue, green }
> >>char cstring[COLORS][] = [red: "red", blue: "blue", green: "green"];
> >>
>

"Achilleas Margaritis" <axilmar@in.gr> ha scritto nel messaggio news:bh8473$11cp$1@digitaldaemon.com...

> There is an easier way, in my opinion than enums: the set. A 'set' could
be
> a foundamental element of the language. A set could contain anything, not only integers. Of course, integers would be automatically enumerated. Its syntax could be:
>
> <type> set <name> = { <comma separated list of values> }
> [...]
> It would certainly be better than simple enums; more readable, strongly
> typed; it would be of user-defined size (so structs that map to binary
> formats would be easier to code); the run-time type static information
would
> be useful to gui IDEs...there are many advantages to it.

I personally find this to be a great idea but, as far as I understand, set
is not the appropriate name for it, maybe due to my Pascal / Delphi
background...
What you described is very nice, but looks in the middle between
enumerations and associative arrays, plus some cool features of its own.
I'd prefer a different keyword to be used for it it if ever gets
implemented, leaving out "set" in the hope that one day D has Pascal-like
sets, which I really miss when I use C / C++.

Ric