DIP idea: q{}-inspired block mixins

[data pulverizer]

On Thursday, 5 November 2020 at 12:51:38 UTC, Jacob Carlborg 
wrote:
>
> 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

Something like the code below seems innocuous to me and is not 
allowed in template mixins.


```
mixin template loop1(long n, T = double)
{
   T x = 0;
   for(long i = 0; i < n; ++i)
   {
     x += cast(T)(i)^^2.0;
   }
}

```

Maybe there is a case for relaxing the rules on for, while, and 
so on?