It is a good point though, no? Could be something of a footgun for performance. Using the example from the talk, if I call "square(3)" in a non-constexpr context and the function is inlined, then compiler will happily constant-fold the i*i expression in the naive version and give you the right result. If you then try to "improve" the naive version by giving a fast runtime-only version protected by a std::is_constant_evaluated() branch, then the compiler must choose the runtime branch because it's not being evaluated in a manifestly constant context. Here's an example of what I mean: godbolt.org/z/b81c8j, notice that the naive version leads to a compile-time constant whereas the "optimized" version is *forced* by the use of std::is_constant_evaluated() to emit the function call (or asm block or CPU intrinsic or whatever) if the caller forgets to force the compile-time evaluation of the function. Normally it's not a big deal whether or not you assign constant expressions to constexpr variables or just use them directly, because constexpr functions are always available to be inlined and constant-folding makes them disappear from codegen. But not with std::is_constant_evaluated(), where now an inlined constexpr function can get stuck at a runtime-only construct the compiler can't optimize.
Can someone explain the cray cray syntax @19:48?????? I can't grok how that's the correct syntax at all. But trying to "fix" the syntax to what I think makes sense doesn't work. So these looks like typos to me but aren't??? Even after decades, I don't understand C++ apparently. :( In the capture list, why are the ellipses `...` BEFORE `args`? And why only on the first `args` but not the second??? I would have thought it should be: [ f = std::move(f), args...= std::move(args...) ] OR AT LEAST [ f = std::move(f), ...args = std::move(...args) ] But nope. Neither of these compiles. I'm so confused!
I like {} initialization. When I'm rummaging through code and I see a{ 5 } I know for a fact this is the first time it's been initialized. That information is uncertain with a = 5. As for a{ 5 } vs a(5), I find the former more consistent with my above preference. But yes, I agree that there shouldn't be what's practically a 99% overlap between two syntaxes.
@@AM-qx3bq well I think using () means calling a constructor and all of its subroutines, and {} is for direct data initialization. So both have their different usage.
I'm pretty sure he's wrong about how constexpr functions work. This is especially true when using is_constant_evaluated. He says that the function will be computed at compile time if all the inputs are constexpr. BUT I'm pretty sure it's only guaranteed to be computed at compile time when the function is called in a constexpr context. I've checked it using a test program similar to what he has at 45:00: int a = square(3); // runtime square(3); // runtime const int c = square(3); // compile time constexpr int d = square(3); // compile time
I think allowing overloading on constexpr-ness would have been the right call anyways. Imo that would be much more readable too because overloads are already intuitive
54:57 Something I don't understand: the value of the cases can only be a value of the enum class (in this case rgba_color_channel), so why do you need to specify it in the first place and just omit it. I mean, the compiler should be smart enough to figure that out (and in Java I think that works).
I think the main thing would be having `static staticinit Colour` is not very readable. With `constinit` you don't have to worry about `const constinit Colour` because it is actually `constexpr Colour` at that point. I do agree that `static` has too many meanings in C++ (and even in C), it should be either a lifetime specifier (a la static scoped variables) or a compile-time specifier (a la `static_cast`, `static_assert`), not both, but at the rate C++ makes breaking changes, you're better off writing a new language (see Rust and their `static`).
The square() function at 49:00 is really dreadful. So now you have a way for your function to behave differently depending on the not-so-trivial evaluation of constness of it? Good luck finding those bugs!
Actually, to reduce bloated callsites for the more common runtime case, I'd probably only rename the compile time one, so "square_consteval() and square ()"
It makes no sense to put a `static` variable in a header. There will be a copy of the variable in each translation unit. Should be declared as `inline Colour` instead.
"You don't need "make" functions anymore" Not quite true; in fact, for tuple and pair the deduction guides are nutty to the point where you're better off sticking with make_tuple and make_pair because they're much less likely to surprise you. For example, CTAD for a declaration of a tuple containing a single pair will invoke the user-defined conversion instead of building a tuple containing a pair, as you almost certainly intend. This makes CTAD for tuple and pair useless in generic contexts, which are the only contexts where using pair or tuple is a good idea anyway.
would be nice if we had `if (consteval (variable))` where `consteval` is an operator like `noexcept` instead of `if (std::is_constant_evaluated())` I'm not actually sure how you'd make that work tbh… Just thought it'd be nice
The original proposal had a new syntax that was either `if constexpr()` or `if (constexpr())` (I forget which, maybe both at some point). I think it's pretty clear the committee preferred to have another "magic function" instead of introducing any language syntax changes.
Since the question if std::is_constant_evaluated() shouldn't use an if constexpr rather than if is so common, shouldn't we propose to just have any if constexpr condition that in someway relies on std::is_constant_evaluated() be converted to a normal if? I am hoping that all compilers will warn at least.
using namespace is bad, and so will using enum be. The solution for the switch is to just deduce the type of the variable. I'm not going to use using enum.
Now you can truly have all of the brackets in a lambda [](T param){ return param; }
C++ has now officially run out of brackets to use
49:00 if you’re unsure of the evaluation, assign the result of square() to a constexpr variable to force the evaluation to be at compile time.
It is a good point though, no? Could be something of a footgun for performance. Using the example from the talk, if I call "square(3)" in a non-constexpr context and the function is inlined, then compiler will happily constant-fold the i*i expression in the naive version and give you the right result. If you then try to "improve" the naive version by giving a fast runtime-only version protected by a std::is_constant_evaluated() branch, then the compiler must choose the runtime branch because it's not being evaluated in a manifestly constant context.
Here's an example of what I mean: godbolt.org/z/b81c8j, notice that the naive version leads to a compile-time constant whereas the "optimized" version is *forced* by the use of std::is_constant_evaluated() to emit the function call (or asm block or CPU intrinsic or whatever) if the caller forgets to force the compile-time evaluation of the function. Normally it's not a big deal whether or not you assign constant expressions to constexpr variables or just use them directly, because constexpr functions are always available to be inlined and constant-folding makes them disappear from codegen. But not with std::is_constant_evaluated(), where now an inlined constexpr function can get stuck at a runtime-only construct the compiler can't optimize.
Excellent talk and well explained all around!
Can someone explain the cray cray syntax @19:48?????? I can't grok how that's the correct syntax at all. But trying to "fix" the syntax to what I think makes sense doesn't work. So these looks like typos to me but aren't???
Even after decades, I don't understand C++ apparently. :(
In the capture list, why are the ellipses `...` BEFORE `args`? And why only on the first `args` but not the second??? I would have thought it should be:
[ f = std::move(f), args...= std::move(args...) ]
OR AT LEAST
[ f = std::move(f), ...args = std::move(...args) ]
But nope. Neither of these compiles. I'm so confused!
I really wish the committee would specify ONE initialisation convention as best practice and the compilers enforce it
I like {} initialization. When I'm rummaging through code and I see a{ 5 } I know for a fact this is the first time it's been initialized. That information is uncertain with a = 5.
As for a{ 5 } vs a(5), I find the former more consistent with my above preference.
But yes, I agree that there shouldn't be what's practically a 99% overlap between two syntaxes.
@@AM-qx3bq well I think using () means calling a constructor and all of its subroutines, and {} is for direct data initialization. So both have their different usage.
I'm pretty sure he's wrong about how constexpr functions work.
This is especially true when using is_constant_evaluated.
He says that the function will be computed at compile time if all the inputs are constexpr.
BUT I'm pretty sure it's only guaranteed to be computed at compile time when the function is called in a constexpr context.
I've checked it using a test program similar to what he has at 45:00:
int a = square(3); // runtime
square(3); // runtime
const int c = square(3); // compile time
constexpr int d = square(3); // compile time
I think allowing overloading on constexpr-ness would have been the right call anyways. Imo that would be much more readable too because overloads are already intuitive
54:57 Something I don't understand: the value of the cases can only be a value of the enum class (in this case rgba_color_channel), so why do you need to specify it in the first place and just omit it. I mean, the compiler should be smart enough to figure that out (and in Java I think that works).
"We need a keyword for something that isn't const but is statically initialised" "Constinit" "Perfect!"
Would staticinit not have made more sense?
I think the main thing would be having `static staticinit Colour` is not very readable. With `constinit` you don't have to worry about `const constinit Colour` because it is actually `constexpr Colour` at that point. I do agree that `static` has too many meanings in C++ (and even in C), it should be either a lifetime specifier (a la static scoped variables) or a compile-time specifier (a la `static_cast`, `static_assert`), not both, but at the rate C++ makes breaking changes, you're better off writing a new language (see Rust and their `static`).
Yes, I think const is used to widely.
But you're initializing it with a const value
The square() function at 49:00 is really dreadful. So now you have a way for your function to behave differently depending on the not-so-trivial evaluation of constness of it? Good luck finding those bugs!
Maintenance and performance have always been mutually exclusive for the most part.
Would the better alternative be to have different function names such as "fast_square()" and "square()"? That's what I would do
Actually, to reduce bloated callsites for the more common runtime case, I'd probably only rename the compile time one, so "square_consteval() and square ()"
It makes no sense to put a `static` variable in a header. There will be a copy of the variable in each translation unit. Should be declared as `inline Colour` instead.
"You don't need "make" functions anymore"
Not quite true; in fact, for tuple and pair the deduction guides are nutty to the point where you're better off sticking with make_tuple and make_pair because they're much less likely to surprise you. For example, CTAD for a declaration of a tuple containing a single pair will invoke the user-defined conversion instead of building a tuple containing a pair, as you almost certainly intend. This makes CTAD for tuple and pair useless in generic contexts, which are the only contexts where using pair or tuple is a good idea anyway.
Anything language features in this talk get changed/dropped from C++20 since it was given?
would be nice if we had `if (consteval (variable))` where `consteval` is an operator like `noexcept`
instead of `if (std::is_constant_evaluated())` I'm not actually sure how you'd make that work tbh…
Just thought it'd be nice
The original proposal had a new syntax that was either `if constexpr()` or `if (constexpr())` (I forget which, maybe both at some point). I think it's pretty clear the committee preferred to have another "magic function" instead of introducing any language syntax changes.
Since the question if std::is_constant_evaluated() shouldn't use an if constexpr rather than if is so common, shouldn't we propose to just have any if constexpr condition that in someway relies on std::is_constant_evaluated() be converted to a normal if? I am hoping that all compilers will warn at least.
*_eenuum_*
using namespace is bad, and so will using enum be.
The solution for the switch is to just deduce the type of the variable.
I'm not going to use using enum.