Hi Nick/Gordon,
Compile-time exception propagation is certainly an interesting concept, especially considering how poorly compilers do reporting errors for metaprogramming. I actually stumbled across the metatest suite from the same group of libraries not long ago, and it's good stuff. However, I think if we did incorporate it, we'd need a way to make it optional, since there will likely always be people who don't want to pay the extra cost for using exceptions. To enable errors, I don't see how we could get around requiring the do / let notation for propagating monads, but perhaps a little preprocessor magic could disable them? I'll have to think on that.
The do and let notations are general tools for monads - if you need exception propagation only, there is another utility for that in metamonad: the try_ template (http://abel.web.elte.hu/mpllibs/metamonad/try_.html). Instead of writing template <class T1, ..., class Tn> struct my_metafunction : body {}; you write template <class T1, ..., class Tn> struct my_metafunction : try_<body> {}; and it instruments body to propagate errors. As an example demonstrating its usage you can take a look at https://github.com/sabel83/mpllibs/blob/master/libs/metamonad/example/min/mi.... To support the use case when people don't want to pay for exception propagation, I can extend metamonad the following way: when a macro (eg. DISABLE_TMP_EXCEPTIONS) is defined, try_ becomes the identity metafunction. In that case it will have a minimal cost (1 extra instantiation). What do you think? Regards, Abel