• Simen =?UTF-8?B?S2rDpnLDpXM=?= (31/31) Apr 15 2018 In a thread[0] over on D.learn, bauss suggested adding a second
• bauss (6/37) Apr 15 2018 Yes, this would be so much easier, especially for frameworks that

Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:

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

bauss <jj_1337 live.dk> writes:

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.