3 ms·

"if constexpr" introduces a new scope, while "static if" does not. A major divergence, enough to make the features very, very different in terms of what they ca

• WalterBright 1y ago
  That was a giant mistake on C++'s part, as you cannot do this: static if (feature) { int bar() { betty(); }} ... lots of code ... static if (feature) bar(); Forcing a new scope cuts the utility of it about in half, and there's no way around it. But if you need a scope with D's static if: static if (expression) {{ int x; foo(x); }} the extra { } will do it. But, as it turns out, this is rarely desirable.
  • jjmarr 1y ago
    I would use std::enable_if or C++20 concepts. Both work fine for selectively enabling functions.
    • quotemstr 1y ago
      Yes, but not for accommodating missing definitions or platform specific syntax. A true static if MUST allow invalid syntax in branches not taken if it's to fully replace the preprocessor.
    • sfpotter 1y ago
      C++20 concepts are a step in the right direction, but: - D had this feature long before C++ did. - It isn't the same thing as "static if". Without "static if", conditionally compiling variables into classes is much more elaborate, basically requiring subclassing to do, which is not really semantically how subclassing should be used (the result is also way more confusing and oblique than the equivalent directly expressed construct you'd have using "static if").