https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86282
Bug ID: 86282
Summary: Evaluation order in if constexpr expression seems to
be irrelevant for evaluating type traits
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rene.r...@fu-berlin.de
Target Milestone: ---
Created attachment 44309
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44309&action=edit
Demo program to show unexpected evaluation of superfluous conditions in
constexpr if
Hi all,
I have an if constexpr expression in the following format:
```
type t{};
if constexpr (my_concept_1<type> && my_concept_2<decltype(some_fn(t))>)
{
// do something.
}
else
{
// do something different.
}
```
Now, I would have assumed, since I am merely evaluating type traits in an
constexpr statement, that if the first condition is false the second condition
will not evaluated by the compiler. But apparently, the second condition seems
to be evaluate nonetheless, which results in superfluous compiler errors, if
for example, `some_fn` does not exists for `t`, but the existence of `some_fn`
would be already checked in `my_concept_t`, such that the first condition must
fail already.
To give you a context, assume your argument can be either a range or a
non-range value. my_concept_1 would check if the range_concept is fulfilled and
in the second condition we check if the value returned by dereferencing
`begin(t)` fulfils my_concept_2, but only if the first condition is `true`.
The compiler would emit an error, that `begin` is not defined if `t` would be
for example an int.
You can find a code example in the attachment.
I compiled it with gcc-8.1 -std=c++17 -fconcepts
I can surly find a way to work around this, but I was in general interested if
this is by design or if there is something unexpected happening.
Thanks for helping me out.
