Justin C Calvarese Wrote:
> YonggangLuo wrote:
> > i think it's will be a good idea to replace "foreach_reverse" with  "frr". "foreach_reverse" is too long as a keyword
> 
> I agree that foreach_reverse is way too long for a keyword. Also, it has that unslightly underscore.
> 
> I think that frr is a little too short. Since it's a keyword that will be rarely used, newcomers to D will likely get confused.
> 
> I'm "voting" for foreachrev, but here's a whole list of decent alternatives to the current "foreach_reverse" mess:
> 
> 1. foreachrev
> 2. rforeach
> 3. revforeach

The operator overloads use _r for the reverse version so there is precedent to maybe reuse that here. eg.

opAdd and opAdd_r

That said operator overloads never appear explicitly in code outside the class definition so the 'ugly' underscore never gets seen.

foreach and foreach_r

I don't personally find the underscore ugly in the above case when it's only followed by one letter 'r'.

Regan Heath

Regan Heath Wrote:

> Justin C Calvarese Wrote:
> > YonggangLuo wrote:
> > > i think it's will be a good idea to replace "foreach_reverse" with  "frr". "foreach_reverse" is too long as a keyword
> > 
> > I agree that foreach_reverse is way too long for a keyword. Also, it has that unslightly underscore.
> > 
> > I think that frr is a little too short. Since it's a keyword that will be rarely used, newcomers to D will likely get confused.
> > 
> > I'm "voting" for foreachrev, but here's a whole list of decent alternatives to the current "foreach_reverse" mess:
> > 
> > 1. foreachrev
> > 2. rforeach
> > 3. revforeach
> 
> The operator overloads use _r for the reverse version so there is precedent to maybe reuse that here. eg.
> 
> opAdd and opAdd_r
> 
> That said operator overloads never appear explicitly in code outside the class definition so the 'ugly' underscore never gets seen.
> 
> foreach and foreach_r
> 
> I don't personally find the underscore ugly in the above case when it's only followed by one letter 'r'.
> 
> Regan Heath

I seriously doubt this keyword will ever change.  Personally, I would choose the Algol-ish 'rofeach'.
There are many bigger issues with D right now, const-ness, AST, fixing the many
problems in the reference implimentation, creating a front end for gcc that the FSF will accept as part
of the standard distribution, better language documentation (a correct, COMPLETE BNF would be
nice), etc...  I appreciate all the hard work Walter is doing, but he was really premature in calling the
language specification 1.0.  I am writing a real time embedded system application using D and
often run into language deficiencies, const and volatile being the most notable.  The reference
implimentation has many annoying problems, (issues with forward references not working in all areas, offsetof not working in all areas, many others, yes I submitted bug reports).  Submitted bug are not
addressed in a timely manner, I would recommend fixing existing problems before creating new
features (with their own problems).  Compile time functions are cool, but please fix some of the basic
problems first.  Walter has done a lot of great work and I appreciate it, but D is no where near ready
for production use.  D is still too much of a risk for most companies to consider using.

Forest

> a correct, COMPLETE BNF would be nice

Seconded. :)