Bug 2698 – Syntax to parse an identifier from a string, instead of mixin()

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

You missed a third use-case: giving identifiers the names of keywords. This may be significant when interfacing with other languages. (Or even, earlier versions of D!). extern(C) { int __identifier("pure")(int); } __identifier is a keyword in MSVC for this reason. (BTW, if you _were_ going to support the name mangling case, a better syntax would probably be: __identifier("name", "mangle") One situation where this would be useful would be in direct linking to C++ compilers other than DMC/GCC. But I don't think that should be considered at all in this proposal).

Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/5d2d09e6e4b7487ec5c7aea1349e1e2c09fe5bf8 Fix issue 2698 - Implement pragma(mangle, "...") allow all characters in mangle rename symbol_override to mangleOverride and remove ctype.h include Add eol at end of mangle.d https://github.com/D-Programming-Language/dmd/commit/656064c4651c87a41358b012ee6358c0c73d8d92 Merge pull request #2024 from IgorStepanov/pragmamangle Fix issue 2698 - Implement pragma(mangle, "...")

(In reply to Daniel Keep from comment #0) > int __ident(name)() { return __ident("_"~name~"storage"); } Wow, this was an insightful idea from 2009! It has recently been re-discovered in 2015: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1010.md#mixin-identifiers I prefer the __identifier(ident) syntax than mixin(ident), it's less noisy as: 1. it doesn't get highlighted as a keyword. 2. it's clearer what kind of token is being introduced. 3. it doesn't refine the idea of mixin to more than just expressions/statements (i.e. code, not an identifier).

Closing as this would require a DIP and is not an actual bug.

Mathias: so feature requests aren't allowed anymore in bugzilla? It has been marked as an enhancement.

Nick: A couple years ago, at DConf if memory serves me well, the usage of Bugzilla was discussed and it was mentioned that more enhancement requests should go to the DIP queue. I unfortunately don't remember the precise conversation, so I'll try to add more details of my interpretation: - Bugzilla should contain actionable item: if an item cannot be picked up by someone and acted on, it shouldn't be here. - Bugzilla should contain low-controversy items: if an item is controversial it is hardly a bug, but most likely an unintuitive behavior (e.g. `if (array)`). - Bugzilla items should describe problems, not solutions: as the former is a bug report and the later is a proposal. It does not mean that bug report are not free to suggest any solution they see fit, but they should focus on the issue. Essentially, this ensures that issues *can be closed*. This report IMO falls into the last category: it describes a situation and derive two use cases from it. The first use case, calling a C function which is not a valid D identifier, is covered (in what I would say a superior way) by `pragma(mangle)`. The second use case is also interesting, but would need a complete, structured proposal to be evaluated. For example, this issue was created at a time when `format` was most likely not CTFE-able. I'm fairly certain `q{}` did not exist either. Nowadays code generation is much simpler (while still far from perfect), and we should assess whether or not this enhancement still make sense. In any case, it would be an improvement over the current state of things, and would not allow to do anything that we can't do currently. I hope this is clear enough. If you disagree with that reasoning, feel free to continue the discussion and/or to re-open.

It seems feature requests without a dip champion will have to just exist in the memory of forum users then. One compromise would be to add a bugzilla resolution 'DIPNEEDED'. The point of this feature is to avoid writing the whole symbol inside a string just because you need an identifier name to be mixed in.

(In reply to Nick Treleaven from comment #3) > I prefer the __identifier(ident) syntax than mixin(ident) > ... > 3. it doesn't refine the idea of mixin to more than just > expressions/statements (i.e. code, not an identifier). Since then, string mixins can be used in place of a type: https://dlang.org/spec/type.html#mixin_types So it would be consistent to allow mixin identifiers too. They can also now take multiple arguments which are converted to strings and concatenated. I think these changes make using `mixin` a better choice for syntax. static foreach(n; [1,2,3]) { int mixin("foo", n) = n; } assert(foo1 == 1); (In reply to Nick Treleaven from comment #7) > The point of this feature is to avoid writing the whole > symbol inside a string just because you need an identifier > name to be mixed in. The whole *declaration* currently has to be in a string, often just because of the identifier for the declaration.