On Saturday, 4 August 2012 at 08:53:20 UTC, David Nadlinger wrote:
How do you determine what the »local level« is? A string
mixin isn't something you can »call«, just a compile-time
constant string, which can be »evaluated« in a completely
different place than it can be constructed. Maybe some
heuristic could be used, but it's not worth the trouble, in my
opinion.
Mmm I would define it as the first one to call on any templates,
at least if you plan on mixing stuff at that spot, further
called/aliased stuff carries over the same information regardless
how many levels deep it goes. If it began inside a template or
from another function then I really don't know, probably holds
the local scope from that level (or none at all).
Why would it be dirty? String mixins are just compile-time code
generation. Also, using template constraints has almost zero
benefits if overload resolution is not involved anyway –
remember, this is just about the helper function/template
generating the string to be mixed in.
Depending on how many asserts I need to add in the string output
seems a bit much if there may be more for the checks after the
generation than before, or the ratio of checks in the returned
string outweigh the actual code you want; Or so I would think. If
all the checks are static than it won't show up in the
executable, but if you need to output it out to glance over the
generated code it would be quite messy to sift through it,
depending on how complex it got.
But I'm probably wrong.
As I said, there are almost always ways to achieve what you
want without resorting to getting the string representation of
an alias parameter. For example:
---
mixin template BitfieldsOn(alias target, <…>) if
(isIntegral!(typeof(target))) {
mixin({
string code;
// Generate code using "target" as identifier.
return code;
}());
}
mixin BitfieldsOn!(foo, <…>);
I really don't see how that is an improvement. If the only way
to use the mixin properly is the full variable location as a
string (and stringof won't do) than the only acceptable input is
a string; Since strings won't hold the type information...
It ends up with a mixin calling another mixin.
