[Issue 2698] Parameterised identifier

May 14, 2018

https://issues.dlang.org/show_bug.cgi?id=2698 Nick Treleaven <nick@geany.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@geany.org --- Comment #3 from Nick Treleaven <nick@geany.org> --- (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). --

https://issues.dlang.org/show_bug.cgi?id=2698 Mathias LANG <pro.mathias.lang@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |pro.mathias.lang@gmail.com Resolution|--- |INVALID --- Comment #4 from Mathias LANG <pro.mathias.lang@gmail.com> --- Closing as this would require a DIP and is not an actual bug. --

https://issues.dlang.org/show_bug.cgi?id=2698 --- Comment #5 from Nick Treleaven <nick@geany.org> --- Mathias: so feature requests aren't allowed anymore in bugzilla? It has been marked as an enhancement. --

July 16, 2019

[Issue 2698] Syntax to parse an identifier from a string, instead of mixin()

Posted by Mathias LANG

Permalink

Mathias LANG

Permalink

https://issues.dlang.org/show_bug.cgi?id=2698

--- Comment #6 from Mathias LANG <pro.mathias.lang@gmail.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=2698 --- Comment #7 from Nick Treleaven <nick@geany.org> --- 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. --

https://issues.dlang.org/show_bug.cgi?id=2698 --- Comment #8 from Nick Treleaven <nick@geany.org> --- (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. --

Forums