On Sat, Aug 4, 2012 at 1:23 PM, David Nadlinger <s...@klickverbot.at> wrote: > On Saturday, 4 August 2012 at 10:08:34 UTC, Era Scarecrow wrote: >>> >>> --- >>> 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. > > > It's a sketch of an implementation for your template which actually works > with foo being passed only as an alias parameter. It's not a string mixin, > but I tend to avoid exposing string mixins to user code as much as possible > anyway. > > I'm not sure what you mean with »[…] the only acceptable input is a string; > Since strings won't hold the type information...« – the input to BitfieldsOn > is _not_ a string, it is an alias. The trick is that you can refer to it as > »target« inside the mixin template, so the problem of obtaining the »real > name« of something doesn't even arise.
Yes, it's a design I like: - using a standard template gives you problem when you try to 'send' the name in another module, as David demonstrated. - using a string mixin is indeed a little less 'clean', as the use might get his grubby hands on the string and then, who knows what may happen. - but using a mixin template that incorporates a string-generating block is good, as you get the full access to types and symbols and can still incorporate any D code inside the delegate/block. Who here knows that D blocks are also void delegate()'s?