In a thread[0] over on D.learn, bauss suggested adding a second argument to MixinExpressions, such that mixin("foo()", "my mixin") compiles. The use case for the extra argument is as an identifier that will be used in error messages, where the current behavior is to create a virtual file name on the form __FILE__-mixin-__LINE__. Instead of this behavior:

unittest {
    // .\foo.d-mixin-17(17): Error: undefined identifier bar
    mixin("bar();");
}

You would have this behavior:

unittest {
    // My mixin(1): Error: undefined identifier bar
    mixin("bar();", "My mixin");
}

A toy example like this doesn't really show how useful this would be, but in a more complex use case where multiple mixins are generated from different template arguments, in a static foreach, etc, the relevant context may be added by the programmer as he writes the code:

static foreach (i, item; getCodeSources()) {
    mixin(item.generateCode(), "Code source "~i.to!string);
}

When the above code fails on item 15, the error message would immediately show "Code source 15(__LINE__): <Error message>", making it much easier to figure out where to start fixing.

Destroy!

--
  Simen
[0]: https://forum.dlang.org/post/tbyqqefafgzfiltglltd@forum.dlang.org

On Sunday, 15 April 2018 at 10:09:36 UTC, Simen Kjærås wrote:
> In a thread[0] over on D.learn, bauss suggested adding a second argument to MixinExpressions, such that mixin("foo()", "my mixin") compiles. The use case for the extra argument is as an identifier that will be used in error messages, where the current behavior is to create a virtual file name on the form __FILE__-mixin-__LINE__. Instead of this behavior:
>
> unittest {
>     // .\foo.d-mixin-17(17): Error: undefined identifier bar
>     mixin("bar();");
> }
>
> You would have this behavior:
>
> unittest {
>     // My mixin(1): Error: undefined identifier bar
>     mixin("bar();", "My mixin");
> }
>
> A toy example like this doesn't really show how useful this would be, but in a more complex use case where multiple mixins are generated from different template arguments, in a static foreach, etc, the relevant context may be added by the programmer as he writes the code:
>
> static foreach (i, item; getCodeSources()) {
>     mixin(item.generateCode(), "Code source "~i.to!string);
> }
>
> When the above code fails on item 15, the error message would immediately show "Code source 15(__LINE__): <Error message>", making it much easier to figure out where to start fixing.
>
> Destroy!
>
> --
>   Simen
> [0]: https://forum.dlang.org/post/tbyqqefafgzfiltglltd@forum.dlang.org

Yes, this would be so much easier, especially for frameworks that relies on user code to mixin, in which case you or the user don't really know the exact line of the resulting mixin.

If this requries a DIP I wouldn't mind writing one, but it seems to be such a small trivial thing though.