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