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