[Issue 8727] __traits(is_reserved_word, "") ?
https://issues.dlang.org/show_bug.cgi?id=8727 RazvanN changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #10 from RazvanN --- Walter has opposed the dmd PR and having this in phobos will lead to inconsistencies once new keywords are added. I think that for niche cases, one can simply create a list of keywords and use it. As for now, a compelling case for adding this in the compiler has not been made. Closing as WONTFIX. --
[Issue 8727] __traits(is_reserved_word, "") ?
https://issues.dlang.org/show_bug.cgi?id=8727 RazvanN changed: What|Removed |Added Keywords||bootcamp CC||razvan.nitu1...@gmail.com --
[Issue 8727] __traits(is_reserved_word, ) ?
https://issues.dlang.org/show_bug.cgi?id=8727 naptime naptimeentertainm...@gmail.com changed: What|Removed |Added CC||naptimeentertainment@gmail. ||com --
[Issue 8727] __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #9 from Andrej Mitrovic andrej.mitrov...@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: ---
[Issue 8727] __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727
--- Comment #8 from bearophile_h...@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: ---
[Issue 8727] __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727 monarchdo...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #6 from monarchdo...@gmail.com 2012-10-10 00:27:20 PDT --- (In reply to comment #5) OK, I think this can be implemented as a library trait. Anyone want to send a pull request that adds it to std.traits? I can do it. I'll use the list here: https://github.com/D-Programming-Language/dmd/blob/82ebe0357511c60b3526682afd8c2209a0861c48/src/lexer.c#L2806 Re-opening. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8727] __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727
--- Comment #7 from monarchdo...@gmail.com 2012-10-10 10:09:19 PDT ---
(In reply to comment #6)
(In reply to comment #5)
OK, I think this can be implemented as a library trait.
Anyone want to send a pull request that adds it to std.traits?
I can do it.
I'll use the list here:
https://github.com/D-Programming-Language/dmd/blob/82ebe0357511c60b3526682afd8c2209a0861c48/src/lexer.c#L2806
Re-opening.
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. I'm dumping my work here. May someone who cares for this (bearophile?) take
over it.
//
/**
If $(D s) is a D reserved keyword, returns true.
*/
bool isReservedWord(in string s)
{
//Obtained from lexer.c, and sorted
string[] reservedWords =
[
__FILE__, __LINE__, __argTypes, __gshared, __overloadset,
__parameters, __thread, __traits, __vector, abstract, alias,
align, asm, assert, auto, body, bool, break, byte, case,
cast, catch, cdouble, cent, cfloat, char, class, const,
continue, creal, dchar, debug, default, delegate, delete,
deprecated, do, double, else, enum, export, extern, false,
final, finally, float, for, foreach, foreach_reverse,
function, goto, idouble, if, ifloat, immutable, import, in,
inout, int, interface, invariant, ireal, is, lazy, long,
macro, mixin, module, new, nothrow, null, out, override,
package, pragma, private, protected, public, pure, real,
ref, return, scope, shared, short, static, struct, super,
switch, synchronized, template, this, throw, true, try,
typedef, typeid, typeof, ubyte, ucent, uint, ulong, union,
unittest, ushort, version, void, volatile, wchar, while,
with
];
auto found = reservedWords.assumeSorted().equalRange(s);
return !found.empty;
}
void main()
{
//obtained from lexer.c, not sorted
string[] words =
[
this, super, assert, null, true, false, cast, new,
delete, throw, module, pragma, typeof, typeid, template,
void, byte, ubyte, short, ushort, int, uint, long,
ulong, cent, ucent, float, double, real, bool, char,
wchar, dchar, ifloat, idouble, ireal, cfloat, cdouble,
creal, delegate, function, is, if, else, while, for,
do, switch, case, default, break, continue, synchronized,
return, goto, try, catch, finally, with, asm, foreach,
foreach_reverse, scope, struct, class, interface, union,
enum, import, mixin, static, final, const, typedef,
alias, override, abstract, volatile, debug, deprecated,
in, out, inout, lazy, auto, align, extern, private,
package, protected, public, export, body, invariant,
unittest, version, __argTypes, __parameters, ref, macro,
pure, nothrow, __thread, __gshared, __traits, __vector,
__overloadset, __FILE__, __LINE__, shared, immutable
];
foreach(ss; words)
assert(isReservedWord(ss));
assert(!isReservedWord(foo));
//CTFE:
static assert(isReservedWord(this));
static assert(!isReservedWord(bar));
}
//
So yeah, not assigned to me anymore :(
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8727] __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #5 from Alex R�nne Petersen a...@lycus.org 2012-10-10 02:46:53 CEST --- OK, I think this can be implemented as a library trait. Anyone want to send a pull request that adds it to std.traits? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8727] __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Keywords||pull CC||a...@lycus.org --- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-09-26 17:03:16 CEST --- https://github.com/D-Programming-Language/dmd/pull/1144 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8727] __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727 --- Comment #2 from bearophile_h...@eml.cc 2012-09-26 08:30:14 PDT --- (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.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8727] __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Comment #3 from monarchdo...@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: ---
[Issue 8727] __traits(is_reserved_word, ) ?
http://d.puremagic.com/issues/show_bug.cgi?id=8727 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #4 from Jonathan M Davis jmdavisp...@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: ---
