DIP idea: q{}-inspired block mixins

[Q. Schroll]

On Thursday, 5 November 2020 at 12:51:38 UTC, Jacob Carlborg 
wrote:
> To be able to specify the name of the property the whole 
> template mixin needs to be replaced with a string mixin. What 
> if we instead could allow string mixins in more locations?

Something like that has been proposed before, called "mixin 
identifiers"; everywhere an Identifier would be valid, one could 
use a string mixin to generate and splice in the identifier. Of 
your example,

mixin template property(T, string name)
{
     private T mixin(name)_;
     T mixin(name)() { return mixin(name)_; }
//    -----------
}

only the highlighted part would word. The other parts don't make 
sense; mixins don't "connect" with surrounding tokens. If `name` 
is "prop", `mixin(name)_` cannot become `prop_`. No kind of mixin 
does that; not even my DIP proposes that.

Borrowing from your example, you'd do:

mixin template property(T, string name)
{
     mixin[name, name_ = name ~ "_"]
     {
         private T name_;
         T name() { return name_; }
     }
}

which reads very well, I guess. I'm not opposed to mixin 
identifiers, since they tackle a not-so-rare use-case. Another 
proposal was being able to mix in the name of something that's 
being declared. In your example, that would be the variable name_ 
and the function name(), but it wouldn't tackle `return name_;`. 
I'd call it mixin declarations, but that name is already taken by 
string mixins that are in a declarative scope (module, struct, 
union, class, interface, template). Mixin identifiers would e.g. 
allow you to mix in parameter type names and parameter names. 
Since @ isn't part of an attribute, @mixin(..) would also work, 
since the grammar says @ Identifier is valid. (Funny enough, "@ 
safe" [note the space] works perfectly, but no-one uses it.)

Maybe I'll make Mixin Identifiers part of the DIP. Let me know 
what you think.