{"id":103553,"date":"2020-03-11T07:00:00","date_gmt":"2020-03-11T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=103553"},"modified":"2020-03-10T18:43:59","modified_gmt":"2020-03-11T01:43:59","slug":"20200311-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20200311-00\/?p=103553","title":{"rendered":"How can I create a type-dependent expression that is always false?"},"content":{"rendered":"

Giving a C++ lambda expression more than one operator()<\/code><\/a> was an abuse of the language.\u00b9 But one of the side effects of exploring ways to abuse the language is that during your explorations, you may discover a useful trick<\/a>.<\/p>\n

One of the things I had to do was prevent compilation from succeeding if the lambda was called incorrectly. I had a chain of if constexpr<\/code> tests for the valid cases, and I needed to put a static_assert<\/code> in the else<\/code> that said “You should never get here.”<\/p>\n

auto lambda = [total<\/span>](auto op, auto value) mutable\r\n{\r\n  using Op = decltype(op);<\/span>\r\n  if constexpr<\/b> (std::is_same_v<Op, add_tax_t><\/span>) {\r\n   total += total * value; \/\/ value is the tax rate<\/span>\r\n   return total;<\/span><\/span>\r\n  } else if constexpr<\/b> (std::is_same_v<Op, apply_discount_t><\/span>) {\r\n   total -= std::max(value, total); \/\/ value is the discount<\/span>\r\n   return total;<\/span><\/span>\r\n  } else<\/b> {\r\n   static_assert(false,<\/b> \"Don't know what you are asking me to do.\");\r\n  }\r\n};\r\n<\/pre>\n
However, this does not compile because the static_<\/code>assert<\/code> fails immediately.<\/p>\n
The reason is that the controlling expression for the static_<\/code>assert<\/code> is not dependent upon the type of the arguments, and therefore it is evaluated when the lambda is compiled, not when the lambda is invoked (and the implicit template instantiated).\u00b2<\/p>\n
In order to defer the static_<\/code>assert<\/code> to instantiation, we need to make it type-dependent.<\/p>\n
What is a type-dependent expression that is always false?<\/p>\n
We could always make up our own:<\/p>\n
template<typename T>\r\ninline constexpr bool always_false_v = false;\r\n\r\n...\r\n\r\n static_assert(always_false_v<Op><\/span>,\r\n               \"Don't know what you are asking me to do.\");\r\n<\/pre>\n
but it feels weird creating a whole new variable template just to generate a fixed false<\/code> value.\u00b3 Maybe we can live off the land.<\/p>\n
We could take advantage of the fact that sizeof<\/code> is never zero.\u2074<\/p>\n
 static_assert(!sizeof(Op)<\/span>,\r\n               \"Don't know what you are asking me to do.\");\r\n<\/pre>\n
but this runs into problems if Op<\/code> is an incomplete type or void<\/code>. Now, the way we happen to have written our code, an incomplete type and void<\/code> are not possible because the type corresponds to an actual parameter. But let’s look for a more general solution.<\/p>\n
If the type is indeed incomplete or void<\/code>, then the code will fail to compile, but the error message will be confusing because the provided error text will not be used: The error occurred before the compiler could get that far.<\/p>\n
However, pointers to<\/i> incomplete types or void<\/code> are valid. So we could do this:<\/p>\n
 static_assert(!sizeof(Op*)<\/span>,\r\n               \"Don't know what you are asking me to do.\");\r\n<\/pre>\n
A static assertion of a type-dependent expression that is always false is a handy thing to put into templates, because it defers the assertion failure to the instantiation of the template. Here, we used it in a potentially-discarded statement, so that the instantiation does not occur when the statement is discarded.<\/p>\n
We’ll find another use next time.<\/p>\n
Bonus chatter<\/b>:  Billy O’Neal<\/a> called out some gotchas with this approach, which I’ll take up in a future entry.<\/p>\n
\u00b9 What some people call an abuse of the language others call a proxy object<\/i>, such as the one produced by std::vector<bool><\/code>‘s []<\/code> operator.<\/p>\n
\u00b2 This does raise a confusing point in the C++ standard. According to the standard, the not-used branch of an if constexpr<\/code> is a discarded statement<\/i>. This is the only place where the term discarded statement<\/i> appears in the standard. And it is never defined! The closest thing to a definition is the sentence<\/p>\n
During the instantiation of an enclosing templated entity (Clause 17), if the condition is not value-dependent after its instantiation, the discarded substatement (if any) is not instantiated.<\/p><\/blockquote>\n
which describes a discarded sub<\/u>statement<\/i>. And it doesn’t really define what a discarded substatement is. It just names one characteristic of discarded substatements.<\/p>\n
I think the standard intended the sentence to be something like<\/p>\n
A discarded statement<\/i> is treated the same as a statement, except that<\/u> during the instantiation of an enclosing templated entity (Clause 17), if the condition is not value-dependent after its instantiation, the discarded statement (if any) is not instantiated.<\/p><\/blockquote>\n
\u00b3 See  the proposal for std::dependent_<\/code>false<\/code><\/a> (and  committee sentiment<\/a>) for further discussion.<\/p>\n
\u2074  Empty base optimization<\/a> and  [[no_<\/code>unique_<\/code>address]]<\/code><\/a> also scare me, because they can lead to an object having an effective size of zero. I don’t want to get caught out if a future version of the standard makes some subtle changes that lead to sizeof(T) == 0<\/code> in some fringe cases.<\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
Use information that you know to be true (or false).<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-103553","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Use information that you know to be true (or false).<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/103553","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=103553"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/103553\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=103553"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=103553"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=103553"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}