Hi,

I think there are some situations where this would be useful. It would
be an easy way to write "for every possible value of this enum,
do ...". As far as I can see, adding this wouldn't break the syntax
(much):

foreach (myEnumType e; myEnumType) {
  doSomething(e);
}

Doesn't look so bad to me. Any comments?

Enums aren't necessarily linear, but it would be useful in the cases that the enum doesn't have gaps and goes in steady progression.

I suppose it could work for nonlinear enums too, but it would have to be completely unrolled by the compiler.

Sean

"Maik Zumstrull" <Maik.Zumstrull@gmx.de> wrote in message news:blh0jt$1qov$1@digitaldaemon.com...
> Hi,
>
> I think there are some situations where this would be useful. It would
> be an easy way to write "for every possible value of this enum,
> do ...". As far as I can see, adding this wouldn't break the syntax
> (much):
>
> foreach (myEnumType e; myEnumType) {
>   doSomething(e);
> }
>
> Doesn't look so bad to me. Any comments?

Sean L. Palmer schrieb:

> Enums aren't necessarily linear, but it would be useful in the cases that the enum doesn't have gaps and goes in steady progression.

I think it would be useful _especially_ in case of non-linear enums, while only "nice to have" for linear enums. You could use a normal for-loop to iterate over a linear enum (although it would be a somewhat "dirty" approach IMHO - why use the enum abstraction when you treat it as int afterwards anyway).

> I suppose it could work for nonlinear enums too, but it would have to be completely unrolled by the compiler.

Well someone has to unroll it in case of a nonlinear enum, and since unrolling is a really stupid (== simple, straightforward, yet lengthy) task, I think the compiler should do it for me.

"Maik Zumstrull" <Maik.Zumstrull@gmx.de> wrote in message news:blh0jt$1qov$1@digitaldaemon.com...
> Hi,
>
> I think there are some situations where this would be useful. It would
> be an easy way to write "for every possible value of this enum,
> do ...". As far as I can see, adding this wouldn't break the syntax
> (much):
>
> foreach (myEnumType e; myEnumType) {
>   doSomething(e);
> }
>
> Doesn't look so bad to me. Any comments?

It's workable.

Walter wrote:
> 
> "Maik Zumstrull" <Maik.Zumstrull@gmx.de> wrote in message news:blh0jt$1qov$1@digitaldaemon.com...
> > Hi,
> >
> > I think there are some situations where this would be useful. It would
> > be an easy way to write "for every possible value of this enum,
> > do ...". As far as I can see, adding this wouldn't break the syntax
> > (much):
> >
> > foreach (myEnumType e; myEnumType) {
> >   doSomething(e);
> > }
> >
> > Doesn't look so bad to me. Any comments?
> 
> It's workable.

What if this were the job of a reflection module in a future standard library?

   myEnumType [] myEnumTypeReflection=ReflectModuleEnum("module.path.name",myEnumType);

   foreach(myEnumType e; myEnumTypeReflection) {
       doSomething(e);
   }


-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3F7D665C.2999F29@chello.at...
>
>
> Walter wrote:
> >
> > "Maik Zumstrull" <Maik.Zumstrull@gmx.de> wrote in message news:blh0jt$1qov$1@digitaldaemon.com...
> > > Hi,
> > >
> > > I think there are some situations where this would be useful. It would
> > > be an easy way to write "for every possible value of this enum,
> > > do ...". As far as I can see, adding this wouldn't break the syntax
> > > (much):
> > >
> > > foreach (myEnumType e; myEnumType) {
> > >   doSomething(e);
> > > }
> > >
> > > Doesn't look so bad to me. Any comments?
> >
> > It's workable.
>
> What if this were the job of a reflection module in a future standard
library?
>
>    myEnumType []
myEnumTypeReflection=ReflectModuleEnum("module.path.name",myEnumType);
>
>    foreach(myEnumType e; myEnumTypeReflection) {
>        doSomething(e);
>    }

I'm less sure how to do that <g>.

Walter wrote:
> > What if this were the job of a reflection module in a future standard
> library?
> >
> >    myEnumType []
> myEnumTypeReflection=ReflectModuleEnum("module.path.name",myEnumType);
> >
> >    foreach(myEnumType e; myEnumTypeReflection) {
> >        doSomething(e);
> >    }
> 
> I'm less sure how to do that <g>.

What if someone would write a
   "D source" => "general tree structure"
parser (must be hidden in your compiler frontend)?

Then it would be trivial to find the enum definition in the tree (and do a lot of other useful things).

Burton's DIGC goes a long way in parsing D code to strip functions bodys, looks into module dependencies, versions ... and I think a lot of future D tools might be easier to write if there were a reusable D parser module written in D.

I'm currently working on a DMI (D make from import) utility to build applications directly using the import dependencies without any need for makefiles and libraries. Just from the sources: "dmi -Ic:\d -Ic:\dmd\src\phobos main" - the same problem.

Of course, it doesn't make sense for "foreach(...enum...)" alone.
But if you think about how to add a kind of reflection sometime in the future?
Such a library based "soft" reflection could be a cheap solution.

And it wouldn't be a "Walter problem".

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3F7DB2E0.636D1B8F@hls.via.at...
> Burton's DIGC goes a long way in parsing D code to strip functions bodys,
looks
> into module dependencies, versions ... and I think a lot of future D tools
might
> be easier to write if there were a reusable D parser module written in D.

There is a reusable D parser, but it's in C++ right now. Eventually, it should be rewritten in D.

> I'm currently working on a DMI (D make from import) utility to build
applications
> directly using the import dependencies without any need for makefiles and
libraries.
> Just from the sources: "dmi -Ic:\d -Ic:\dmd\src\phobos main" - the same
problem.
>
> Of course, it doesn't make sense for "foreach(...enum...)" alone.
> But if you think about how to add a kind of reflection sometime in the
future?
> Such a library based "soft" reflection could be a cheap solution.

I think supporting reflection is important. But not important enough to do it for the next version, for that I think improving the template support is much more important.

In article <blh0jt$1qov$1@digitaldaemon.com>, Maik Zumstrull says...
>
>Hi,
>
>I think there are some situations where this would be useful. It would
>be an easy way to write "for every possible value of this enum,
>do ...". As far as I can see, adding this wouldn't break the syntax
>(much):
>
>foreach (myEnumType e; myEnumType) {
>  doSomething(e);
>}
>
>Doesn't look so bad to me. Any comments?
>

What would it do with this enum then?
enum myEnumType { Zilch=0 , Zip=0 , Nul=0 , GooseEgg=0 , Nada=0 } ;
will it call doSomething() four times with the value 0 as expected or something
unexpected?

Juan C

Juan C schrieb:

> What would it do with this enum then?
> enum myEnumType { Zilch=0 , Zip=0 , Nul=0 , GooseEgg=0 , Nada=0 } ;
> will it call doSomething() four times with the value 0 as expected or
> something unexpected?

That would have to be defined. I'd prefer it to do only one call per real value, not one for every alias. It could also be made to do all five calls in plain mode and optimize four of them away with enabled optimization. Would/could the optimizer be intelligent enough to optimize four calls away if it recognizes that making all five calls doesn't lead to a different result? In that case, you could write code with the assumption that all five calls are made while they aren't actually made when it's not necessary.