www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8727] New: __traits(is_reserved_word, "") ?

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8727

           Summary: __traits(is_reserved_word, "") ?
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: bearophile_hugs eml.cc



Maybe it's worth adding a new trait that tells what currently are reserved
words of D:

assert(__traits(is_reserved_word, "import"));

For an use case see:
http://d.puremagic.com/issues/show_bug.cgi?id=6946

It replaces a function like this, that risks becoming out of date:

bool isReservedWord(in string w) {
    string[] reservedWords = "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 __FILE__ __LINE__ __gshared
    __thread __traits".split();
    return canFind(reservedWords, w);
}


Such __traits is useful to exclude the reserved words from usages in code
generation, to avoid bugs or avoid mysterious error messages.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 26 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8727


Alex Rønne Petersen <alex lycus.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull
                 CC|                            |alex lycus.org



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: -------
Sep 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8727





 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: -------
Sep 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8727


monarchdodra gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra gmail.com





 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: -------
Sep 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8727


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com



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: -------
Sep 26 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8727


Alex Rønne Petersen <alex lycus.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



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: -------
Oct 09 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8727


monarchdodra gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |




 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: -------
Oct 10 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8727






 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: -------
Oct 10 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8727






 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: -------
Oct 12 2012
prev sibling parent d-bugmail puremagic.com writes:
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



11:23:57 PST ---

 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: -------
Jan 10 2013