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


--- Comment #0 from bearophile_hugs@eml.cc 2012-09-26 07:16:33 PDT ---
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: -------

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


--- Comment #1 from Alex Rønne Petersen <alex@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8727



--- Comment #2 from bearophile_hugs@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: -------

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


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

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


--- Comment #5 from Alex Rønne Petersen <alex@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8727


monarchdodra@gmail.com changed:

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


--- Comment #6 from monarchdodra@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=8727



--- Comment #7 from monarchdodra@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: -------

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: -------