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

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 "!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.



Reply via email to