Re: [boost] dramatically improved template error messages (was: C++11 decltype/SFINAE puzzler)

Subject: Re: [boost] dramatically improved template error messages (was: C++11 decltype/SFINAE puzzler)
From: Andrew Sutton (asutton.list_at_[hidden])
Date: 2012-08-14 16:12:00

> I'd also like to know *why* this works, and indeed if it's guaranteed
> to. In particular, is it guaranteed that the virtual what() member of
> the sfinae_error class is instantiated at the outermost call site and
> not elsewhere (thereby eliminating the deep template back-trace)? I
> really just stumbled on this technique by accident, and I don't know how
> thin the ice is here. Both clang-trunk and gcc-4.7 think it's ok.

I'll wager an explanation... maybe somebody will be able to refine it.

Because what() is virtual, it needs to build the vtable for
sfinae_error. However, because what() isn't actually used in the
program, it is instantiated at the very end of translation. Basically,
the point of instantiation is at the top-level, at the end of the
translation unit. There's no template instantiation stack to unwind.

Comment out the "virtual" keyword in front of what(). The program
should actually compile. The try_call doesn't actually force a
compilation error, it suppresses it. This only works because
sfinae_error happens to be polymorphic.

Using unused virtual functions to defer instantiation traps is
incredibly clever... If my understanding is correct :)

> IMO, this is now approaching something of real value. My personal
> experience using this with Proto-11 is that it dramatically improves
> error messages. I can also easily imagine how this can be used to
> implement a very nice concept-checking library for C++11 that
> approximates auto-concepts. Andrew, any thoughts on this? You've done
> far more work in this space than I have.

I want to say yes, but I'm not sure. What's really needed is a
combination of this and static_assert. I want compilation to stop
*and* I want brief errors. Hmm... Let me get back to you on this.