DIP idea: q{}-inspired block mixins

Jacob Carlborg doob at me.com
Thu Nov 5 12:51:38 UTC 2020


On Thursday, 5 November 2020 at 04:07:06 UTC, Q. Schroll wrote:
> Here is the DIP PR: https://github.com/dlang/DIPs/pull/194 and 
> the DIP document: 
> https://github.com/Bolpat/DIPs/blob/TokenMixins/DIPs/DIP-1NN2-QFS.md
>
> Please let me know of any suggestions that come to your mind in 
> this thread or the PR discussion.

Isn't it quite rare to have the mixin location and the string, to 
be mixed in, at the same place? For example:

mixin("int a = 3;"); // rare

string generate(string name)
{
     return "int " ~ name " = 3;"; // code is here
}

mixin(generate("a")); // mixin location is here, more common

How will your solution help with that?

Perhaps we can turn the problem around. Instead of doing some 
form of highly specialized string interpolation, that only works 
in one place, instead focus on removing the need to use strings 
in the first place.

In the cases I had the need to use a string mixins, most of the 
code would have worked with a template mixin, but it was just the 
identifier that caused the need to move to string mixins. Example:

mixin template property(T)
{
     private T a_;
     T a() { return a_; }
}

class Foo
{
     mixin property!int;
}

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

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

class Foo
{
     mixin property!(int, "a");
}

I would not call the above a new language feature, just removing 
some limitations.

Or, the solution to all of the above (and many more issues): AST 
transformations [1].

[1] https://wiki.dlang.org/DIP50

--
/Jacob Carlborg



More information about the Digitalmars-d mailing list