2013/10/8 MJanes <max...@gmail.com
> Il giorno lunedì 7 ottobre 2013 19:47:27 UTC+2, Daniel Krügler ha scritto:
>> You won't get that. What you are asking for is often named
>> "speculative compilation/instantiation".
> even simply detecting static_assert failures ? I mean, as other said,
> currently SFINAE it's the only tecnique usable to test expected compilation
> failure ( apart specialized unit tests ) and the inability of detecting
> static assertion is a real problem IMHO.
Even with that, I suppose. Keep in mind that once you are enforcing
the compiler to instantiate more than needed (e.g. template
definitions compared to template declarations), this won't stop the
compiler from doing the complete job. If you have within a constructor
that direct-initializes X with Y a static_assert that validates
is_constructible<X, Y>, there is not only the failure of the
static_assert, but also the expected error or the
But that's not all: Typically the static_assert predicates are
themselves templates that need to be instantiated. What happens if
*within* this instantiation a static_assert fails? Does this have the
effect of returning false or is this a compile-error?
Current SFINAE is localized to the *immediate* context for good
reasons: It is intended to keep template compile overhead to the "top"
> Considering that you can often ( always? ) turn any static assert into a
> sfinae failure with equivalent behavior ( at least with respect to detecting
> the error one is interested in ), I wonder why detecting static asserts (
> and only them, not any possible non-well-formedness ) would qualify as
> speculative compilation ...
Because they (a) can occur in any instantiation depth and (b) because
the compiler still has to consider the surrounding code,
static_asserts are not isolated in general, so from a compiler
perspective there is not much difference between applying your rule
"only" to static_asserts compared to general speculative compilation.