5 ms·

Move semantics is only needed because C++ introduced implicit copies (copy constructor) and they of course fucked it up my making them non-destructive so they a

Move semantics is only needed because C++ introduced implicit copies (copy constructor) and they of course fucked it up my making them non-destructive so they aren't even 'zero cost'. Constexpr and consteval are hacks that 1) should have just been the default, and 2) shouldn't even be on the function definition, it should instead have been a keyword on the usage site: (and just use const) int f() { ... } // any old regular function const int x = f(); // this is always get evaluated at compile time, (or if it can't, then fail to compile) int y = f(); // this is evaulated at runtime That would be the sane way to do compile time functions.

serbuvlad 2y ago
Eh not really accurate because C's const means immutable not actually constant. So I get introducing constexpr to actually mean constant. But, yeah, constexpr x = f() should probably have worked as you described.
- jlokier 2y ago
  const is different in C++ from const in C. const variables in C++ are proper compile-time constants. In C they are not (the nearest equivalents are #define and enum values). So in C++ "const x = EXPR" would make sense to request compile-time evaluation, but in C it wouldn't.
  - OskarS 2y ago
    They absolutely are not. Look at this range for-loop: for (const auto item: vec) { ... } `item` is not a compile-time constant. It's different every run of the loop.
    - jlokier 2y ago
      Ouch, but thanks. I learned something today - something I'd long forgotten. I like your example, it shows the point well. (Though, there are circumstances when a compiler can unroll such a loop and infer a compile-time constant, it wouldn't qualify as a constant expression at the language level.) It's been so long since I used C++ for serious work that we weren't using C++11, so neither auto nor range-for were available. It would be uncommon to see "const type = " with a non-reference type and a non-constant initialiser. Even with your example, some styles avoid "const auto item", using either "auto item" or "const auto& item" instead, because the "const" matters when taking a reference, not so much with a copy. But I appreciate your point applies to const variables with non-constant initialisers in general, in the language. There was once a big deal in literature about const in C++ being the "better" alternative to how #define is commonly used with C for constant values, and it seemed applicable to the thread as a key distinction between C and C++, which the parent commenter seemed to have conflated by mistake. But I'd forgotten about const (non-reference) variables accepting non-constant initialisers, and as I hadn't used C++ seriously in a while, and the language is always changing, I checked in with a couple of C++ tutorials before writing. Unfortunately those tutorials were misleading or too simple, as both tutoruals said nothing about "const type x = " (non-reference/pointer) being uwed in any other way than for defining compile-time constants. It's bit embarrssing, as I read other parts of the C++ standard quite often despite not using it much these days. (I'm into compiler guts, atomics, memory models, code analysis, portability issues, etc.). Yet I had forgotten this part of the language. So, thanks for sending me down a learning & reminder rabbit-hole and correcting my error :-)
blux 2y ago
Could have been if backwards compatibility was not a thing indeed. Move constructors are not needed, they don't solve a 'problem', but improve on previous semantics.
OskarS 2y ago
I agree that I would have preferred destructive moves, but move semantics makes C++ a much richer and better language. I kinda think pre-move semantics, C++ didn't quite make "sense" as a systems programming language. Move semantics really tied the room together. const int x = f(); // this is always get evaluated at compile time, (or if it can't, then fail to compile) That's very silly. You're saying this should fail to compile? void foo(int x) { const int y = bar(x); } There's no way the compiler can run that, because it doesn't know what x is (indeed, it would have a different value every time you run the function with a new argument). So your proposal would ditch const completely except in the constexpr case, everything runtime would have to be mutable. So you respond "well, I didn't mean THAT kind of const, you should have a different word for compile-time constants and run-time non-mutability!" Congratulations, you just invented constexpr. There are many bad things about C++, but constexpr ain't one of them.
- kringlezz 2y ago
  >There's no way the compiler can run that, because it doesn't know what x is (indeed, it would have a different value every time you run the function with a new argument). So your proposal would ditch const completely except in the constexpr case, everything runtime would have to be mutable. Yeah, I see no problem with that. Non-constant expressions usage of 'const' has always just seemed like a waste of time for me, never found it useful. But I guess a lot of people really liking typing const and "preventing themselves from accidentally mutating a variable" (when has that ever happened?), so as a compromise I guess you can have a new keyword to force constant expressions: constexpr auto x = foo(); // always eval at compile time const auto x = foo(); // old timey const, probably runtime but maybe got constant folded. but it's not really a big deal what they keyword is, the main point was that "give me a constant value" should be at the usage site, not at the function definition.
  - vitus 2y ago
    > "preventing themselves from accidentally mutating a variable" (when has that ever happened?) I can't count the number of times I've seen someone new to the language use map::operator[] without realizing that it's a mutating operation.

serbuvlad 2y ago

Eh not really accurate because C's const means immutable not actually constant. So I get introducing constexpr to actually mean constant. But, yeah, constexpr x = f() should probably have worked as you described.

jlokier 2y ago
const is different in C++ from const in C. const variables in C++ are proper compile-time constants. In C they are not (the nearest equivalents are #define and enum values). So in C++ "const x = EXPR" would make sense to request compile-time evaluation, but in C it wouldn't.
- OskarS 2y ago
  They absolutely are not. Look at this range for-loop: for (const auto item: vec) { ... } `item` is not a compile-time constant. It's different every run of the loop.
  - jlokier 2y ago
    Ouch, but thanks. I learned something today - something I'd long forgotten. I like your example, it shows the point well. (Though, there are circumstances when a compiler can unroll such a loop and infer a compile-time constant, it wouldn't qualify as a constant expression at the language level.) It's been so long since I used C++ for serious work that we weren't using C++11, so neither auto nor range-for were available. It would be uncommon to see "const type = " with a non-reference type and a non-constant initialiser. Even with your example, some styles avoid "const auto item", using either "auto item" or "const auto& item" instead, because the "const" matters when taking a reference, not so much with a copy. But I appreciate your point applies to const variables with non-constant initialisers in general, in the language. There was once a big deal in literature about const in C++ being the "better" alternative to how #define is commonly used with C for constant values, and it seemed applicable to the thread as a key distinction between C and C++, which the parent commenter seemed to have conflated by mistake. But I'd forgotten about const (non-reference) variables accepting non-constant initialisers, and as I hadn't used C++ seriously in a while, and the language is always changing, I checked in with a couple of C++ tutorials before writing. Unfortunately those tutorials were misleading or too simple, as both tutoruals said nothing about "const type x = " (non-reference/pointer) being uwed in any other way than for defining compile-time constants. It's bit embarrssing, as I read other parts of the C++ standard quite often despite not using it much these days. (I'm into compiler guts, atomics, memory models, code analysis, portability issues, etc.). Yet I had forgotten this part of the language. So, thanks for sending me down a learning & reminder rabbit-hole and correcting my error :-)

blux 2y ago

Could have been if backwards compatibility was not a thing indeed. Move constructors are not needed, they don't solve a 'problem', but improve on previous semantics.

OskarS 2y ago

I agree that I would have preferred destructive moves, but move semantics makes C++ a much richer and better language. I kinda think pre-move semantics, C++ didn't quite make "sense" as a systems programming language. Move semantics really tied the room together. const int x = f(); // this is always get evaluated at compile time, (or if it can't, then fail to compile) That's very silly. You're saying this should fail to compile? void foo(int x) { const int y = bar(x); } There's no way the compiler can run that, because it doesn't know what x is (indeed, it would have a different value every time you run the function with a new argument). So your proposal would ditch const completely except in the constexpr case, everything runtime would have to be mutable. So you respond "well, I didn't mean THAT kind of const, you should have a different word for compile-time constants and run-time non-mutability!" Congratulations, you just invented constexpr. There are many bad things about C++, but constexpr ain't one of them.

kringlezz 2y ago
>There's no way the compiler can run that, because it doesn't know what x is (indeed, it would have a different value every time you run the function with a new argument). So your proposal would ditch const completely except in the constexpr case, everything runtime would have to be mutable. Yeah, I see no problem with that. Non-constant expressions usage of 'const' has always just seemed like a waste of time for me, never found it useful. But I guess a lot of people really liking typing const and "preventing themselves from accidentally mutating a variable" (when has that ever happened?), so as a compromise I guess you can have a new keyword to force constant expressions: constexpr auto x = foo(); // always eval at compile time const auto x = foo(); // old timey const, probably runtime but maybe got constant folded. but it's not really a big deal what they keyword is, the main point was that "give me a constant value" should be at the usage site, not at the function definition.
- vitus 2y ago
  > "preventing themselves from accidentally mutating a variable" (when has that ever happened?) I can't count the number of times I've seen someone new to the language use map::operator[] without realizing that it's a mutating operation.