[Issue 2698] New: Parameterised identifier

[d-bugmail at puremagic.com]

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

           Summary: Parameterised identifier
           Product: D
           Version: 2.025
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla at digitalmars.com
        ReportedBy: daniel.keep+d.puremagic.com at gmail.com


Proposal: add the following to the D grammar:

Identifier:
    IdentiferStart
    IdentiferStart IdentifierChars
    ParameterisedIdentifier    

ParameterisedIdentifier:
    "__ident" "(" AssignExpression ")"


This allows for two use-cases.  Firstly, it allows the definition of symbols
that do not have valid D identifiers.  The pressing example from the efforts to
port DMD to Mac OSX is the following [1]:

  _blah$UNIX2003

This is an issue with the pthread library in 10.5.  D cannot link to these
functions directly, and a C shim would have to be built.  Instead, this
proposal would allow for the following syntax:

  extern(C) void __ident("blah$UNIX2003")(int);

thus removing the need for a shim.  This need could also be filled by replacing
"AssignExpression" with "StringLiteral", which I assume would be easier to
implement.

The second use-case is in compile-time generated code.  An example might be
generating a set of property accessors and storage, given a name and type.

  mixin Property!("foo", int);

The problem here is that actually creating the functions and storage is fiddly.
 You have to do this within the template or CTFE:

  mixin(`int `~name~`() { return _`~name~`_storage; }`);

Because of how mixin decls work, you have to quote out the entire function just
to replace the identifiers.  The proposal would allow for this:

  int __ident(name)() { return __ident("_"~name~"storage"); }

Admittedly, this is actually longer than the above, but it has the distinct
advantage of not requiring the programmer to stuff about with quoting and
unquoting their code.

In terms of mangling, I believe the symbol should be treated as not being
mangled yet.  If control over this is required (I can't imagine it being of use
except in very extreme circumstances), another proposal could be made to extend
the syntax to allow:

  __ident(name, cast(bool) should_name_be_mangled)


[1]
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=14958


--