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
<newshou...@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
