change mixins

Nick Sabalausky a at a.a
Sun Feb 14 23:31:31 PST 2010


"BCS" <none at anon.com> wrote in message 
news:a6268ff104068cc7bdef4aa51da at news.digitalmars.com...
> Hello Nick,
>
>> "BCS" <none at anon.com> wrote in message
>> news:a6268ff103d38cc7ba48d6fabda at news.digitalmars.com...
>>
>>> Hello Nick,
>>>
>>>> I *definitely* want that for string mixins of both the
>>>> template-generated and ctfe-generated varieties.
>>>>
>>> Why? I don't see any reason aside from documentation to do it.
>>>
>> Well, for one thing, not having it forces any code using my
>> custom-assert library to look like this crap...
>>
>> mixin(deferAssert!(`foo == 3 || foo > 5`, "foo is bad"));
>>
>> ...which understandably no one wants to touch and I *absolutely* don't
>> blame them one bit. Compare that to this...
>>
>> deferAssert!(`foo == 3 || foo > 5`, "foo is bad");
>>
>> ...ahhh, now I can actually see what the hell's going on!
>
> 1) I don't see a lot of difference (I see a /little/ difference), the 
> extra mixin() doesn't get in the way of /me/ seeing what going on.
>

Different people, I guess.

> 2) I'd prefer more general solution, like being able to extract the 
> original string from a lazy parameter or pass expressions as alias:
>
> void deferAssert!(alias exp, string message)
> {
>     if(!exp) // deferAssert gets instanced as a local function (or gets a 
> hidden delegate parameter or wherever)
>        writef("%s failed: %s\n", exp.stringof, message);
> }
>
> 3) anything that passes code around as strings looks like a hack 
> (sometimes necessary) to me and has so many downside relating to tools 
> (particularly syntax highlighters) that the mixin() gets lost in the 
> noise.
>
> void deferAssert!(foo == 3 || foo > 5, "foo is bad"); // ...ahhh, now I 
> can really see what the hell's going on, and so can my tools!
>

Good points, although for now what we have are mixins, and switching the 
mixin label to the declaration-side, I suspect, is a simpler change. And as 
far as the tools seeing it, D2 has q{} strings.






More information about the Digitalmars-d mailing list