http://d.puremagic.com/issues/show_bug.cgi?id=8727
monarchdodra@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |monarchdodra@gmail.com
--- Comment #3 from monarchdodra@gmail.com 2012-09-26 08:52:13 PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > https://github.com/D-Programming-Language/dmd/pull/1144
>
> Thank you, only 45 minutes to see implemented one enhancement request of mine
> :-)
>
> (Regarding the comments inside your patch, "foreach_reverse" is quite useful.
> retro() will be acceptable only if the compiler recognizes it as special and
> guarantees to implement it with the the same efficiency of foreach_reverse in
> all cases. I think this will not happen, so I'll try to keep "foreach_reverse"
> inside the language.)
I don't want to hijack this pull request into off topic discussion, but is
foreach_reverse *really* scheduled for deprecation? Or is this just an ongoing
suggestion. If it is an ER, do you have a link to it?
IMO, The problem with retro is that it does not support natural slice syntax:
--------
import std.range;
import std.stdio;
void main()
{
foreach_reverse(i; 0..10)
writeln(i, "...");
writeln("Fire!");
foreach(i; retro(0..10)) //NOPE
writeln(i, "...");
writeln("Fire!");
}
--------
The equivalent code would require inserting an iota. Either from 9 to -1 (ew),
or from 0 to 10, then reversed (blargh):
--------
void main()
{
foreach_reverse(i; 0..10)
writeln(i, "...");
writeln("Fire!");
foreach(i; iota(9, -1, -1)) //Ew
writeln(i, "...");
writeln("Fire!");
foreach(i; iota(0, 10).retro() ) //Blargh
writeln(i, "...");
writeln("Fire!");
}
--------
Looking only at the syntax, I'd like to keep foreach_reverse thankyou very
much. I also doubt that the performance is anywhere near the same level.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8727
Jonathan M Davis <jmdavisProg@gmx.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jmdavisProg@gmx.com
--- Comment #4 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-09-26 10:15:44 PDT ---
> I don't want to hijack this pull request into off topic discussion, but is
foreach_reverse *really* scheduled for deprecation?
I haven't gotten a clear answer on that. I don't think that there's much
question that if we were completely redoing things, it wouldn't be in the
language, and there's a definite contingent who want it gone. But I don't know
whether Walter intends to axe it or not. AFAIK, no definitive decision was made
on it. It's not on the list of features to be deprecated on dlang.org:
http://dlang.org/deprecate.html
There's probably a good chance that foreach_reverse will cease to work with
delegates at some point even if it's kept, because it does exactly the same
thing as foreach for delegates, making it a source of bugs. But there's
probably a good chance that foreach_reverse is here to stay simply to avoid
breaking code even if it's certain that we don't want it.
Regardless, if you want someone like Walter who would know for sure what
foreach_reverse's current fate is supposed to be, you'll probably have to post
in the newsgroup (and short of Walter or Andrei saying something, I don't know
if you can know for certain what the current situation is, since it's Walter's
decision, and I'm not aware of him making a public decision on it).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8727
--- Comment #8 from bearophile_hugs@eml.cc 2012-10-12 14:24:14 PDT ---
(In reply to comment #7)
> bool isReservedWord(in string s)
> {
> //Obtained from lexer.c, and sorted
> string[] reservedWords =
> [
> "__FILE__", "__LINE__", "__argTypes", "__gshared", "__overloadset",
...
The problem with putting a list of words like this in Phobos is that if a new
keyword is added, this function breaks. So it's better for this function to be
built inside __traits() and to use the list of keywords used by the compiler
itself.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8727
Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andrej.mitrovich@gmail.com
--- Comment #9 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-01-10 11:23:57 PST ---
(In reply to comment #7)
> I wrote the code, the documentation, and the unit tests. The thing though is
> that I don't really care for this enhancement, and don't feel like pushing for
> it.
This is actually very useful for generic code, it allows one to generate
identifiers while ensuring they don't conflict with keywords.
It's also useful in code generators written in D, which can use this function
to generate C/C++ wrappers code which doesn't conflict with D keywords.
I'd say make it a pull, it's your work after all. :)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------