Metaprogramming in D : Some Real-world Examples

[grauzone]

Andrei Alexandrescu wrote:
> grauzone wrote:
>> Lars T. Kyllingstad wrote:
>>> Jacob Carlborg wrote:
>>>> On 11/10/09 01:27, Bill Baxter wrote:
>>>>> On Mon, Nov 9, 2009 at 4:09 PM, Walter Bright
>>>>> <newshound1 at digitalmars.com>  wrote:
>>>>>> Looks like Bill Baxter is giving a presentation on D Nov. 18!
>>>>>>
>>>>>> http://www.nwcpp.org/
>>>>>
>>>>> Yep, that's right, and I'd be quite grateful to you smart folks here
>>>>> if you could share your meta-programming favorites with me!   If
>>>>> you've got a real-world example of meta-programming in D that you
>>>>> think is particularly handy, then please send it my way
>>>>>
>>>>> I'm looking for small-but-useful things that are easy to explain, and
>>>>> make something easier than it would be otherwise.  Things like places
>>>>> where static if can save your butt,  or loop unrolling,  and passing
>>>>> code snippets to functions like in std.algorithm.
>>>>>
>>>>> Things like a compile-time raytracer or regexp parser (though quite
>>>>> cool!) are not what I'm after.  Too involved for a short talk.
>>>>>
>>>>> --bb
>>>>
>>>> This is invaluable to me, which makes it possible to do some form of 
>>>> duck typing at compile time:
>>>>
>>>> static if (is(typeof({
>>>> /* does this compile */
>>>> })))
>>>
>>> There are forces at work (Don, that is) attempting to get rid of that 
>>> very construct and replace it with something better:
>>>
>>> http://www.digitalmars.com/d/archives/digitalmars/D/Proposal_Replace_traits_and_is_typeof_XXX_with_a_magic_namespace_._99914.html 
>>>
>>>
>>> In my humble opinion, is(typeof({...})) is an ugly creature. I really 
>>> don't think it should be put under a spotlight as a good example of D 
>>> metaprogramming. If anything, please use __traits(compiles, {...}) 
>>> instead.
>>
>> Who cares about "ugly" syntax, if the idea is bad in the first place?
> 
> I think testing types during compilation isn't bad. Under what 
> circumstances is it?

You're not testing for types, you're testing if it compiles. Inside the 
tested block of code, all sorts of things could go wrong. You can't know 
if is(typeof(...)) really did what you wanted, or if something broke. At 
least when you're doing more complex stuff with is(typeof), the danger 
of silent failures increases. Suppose the user makes an error in his 
custom range type by specifying a wrong return type (or whatever), and 
the range library just ignores his range-related function. Maybe that 
range function was optional, which will end in the range library 
seemingly ignoring his function. Can this be good? (I don't know if that 
case I described can even happen in your ranges lib, but I think this is 
a typical failure that could happen with is(typeof).)

This isn't even compiletime duck typing anymore, it's try-and-error 
built into the compiler. Even worse, now having semantically incorrect 
code in D sources is perfectly fine for weird reasons, and the compiler 
has to "swallow" some kinds of semantics errors.

Really, wouldn't some mechanism to explicitly check for compile time 
contracts better?

For me, this is some sort of metaprogramming WTF. This all makes me 
cringe. Sorry about that.

> Andrei