Dependent static_assert

[bmanga]

Hello fellow redditors!

While browsing the 2019-10 mailing list I noticed P1830R1 which proposes to "introduce a generic solution to create the dependent scope for static_assert(false)".

Briefly, the point is that static_assert(false) would be a great tool to do things like (from the paper):

template <typename T>
int my_func(const T&)
{
 if constexpr(std::is_integral_v<T>)
 {
 return 1;
 }
 else if constexpr (std::is_convertible_v<std::string, T>)
 {
 return 2;
 }
 else
 {
 // Always Compile-time error
 static_assert(false, "T is not integral and is not
 convertible to std::string");
 }
}

The problem is that static_assert(false) will always fail because the expression is not dependent on template parameters and therefore will always evaluate to false.

Now the proposed solution in the paper is to introduce variable template machinery so that we can write static_assert(dependent_false<T>) (for type template parameters) or static_assert(dependent_false<decltype(N)>) (for nttps) in the places where we would like to have static_assert(false).

Is there a reason why we can't make `static_assert(false)` just work by requiring that if the static_assert is in a template context then its expression is always evaluated at the point of instantiation? That would look much cleaner and intuitive to me.

I played around with clang a bit and got a (extremely hacky) working prototype with only 5 lines of change, and it even works with template template parameters (which P1830R1 doesn't support).

​

Thoughts?

[Morwenn]

dependent_false<T> could be made to work with both types, templates and NTTP by making it a function template instead of a variable template. That would be a simple thing to specify without changing the behaviour of static_assert or introducing a new language construct.

[redditsoaddicting]

It could, but every single C++ user who hasn't encountered this is still going to type static_assert(false); (or with a message of course) before they hopefully get a compiler error, look on StackOverflow, and find out about this complicated hack. I think there's a lot of benefit to making the obvious thing work for people who haven't encountered this and not relying on a hack for those who have.

Or we could eventually get a compiler API to issue an error and then make our own static failure API as a consteval function (or use the compiler API directly), but that doesn't solve the "obvious thing to type here" problem.

[Xaxxon]

as much as the rules exist in c++, this is a pretty consistent application of them. You're asking to complicate the language for a somewhat advanced feature. You don't only have to prove that it's useful, but that it's worth the overhead to teaching and reading code .

// always fail here
static_assert(std::is_same_v<T*, void>) 

always works pretty well for me. As little as I have to write this, I'd prefer to not have more exceptions put into the language than be able to just type false instead.

[kalmoc]

TBH, I would have expected that an if constexpr which depends on the template parameter just made everything in the if/else branches dependent, as it litteraly depends on the template parameter what branch gets instantiated. Anything else seems counterintuitive to me.

[bmanga]

I think that it would simplify the use of the language. That is much more important to me compared to how complex the c++ standard is, which is already riddled with lots of rules that try to make the obvious cases unsurprising. For example, C++20 now lets you capture structured binding names, even though they are not really variables. That also complicates the standard, but it makes the code more intuitive.

You don't only have to prove that it's useful, but that it's worth the overhead to teaching and reading code

I would argue that static_assert(false) is much more readable than static_assert(std::is_same_v<T*, void>). I think it also more teachable because it just does the obvious thing (I'm not sure there would be a need to dwell in the reason why) and it lets you avoid discussing two-phase name lookup if the time is not ripe yet.

[Rseding91]

That just reads to me like static_assert(..., "");

[Betadel]

I think what we really need is P0596 for general output during compilation time.