This is a great language design talk. My intuitive advice is to not make any more changes in the language around this topic. It will only create new problems and make learning C++ even longer. Whatever horrible state exists now is workable, as proven by successful projects. And it can be taught to motivated experts. If we add more stuff, even experts will just stop caring and will start just randomly changing code until it works. Sadly, most beginner programmers already do that very often.
On slide 14, the two variables of type A have disjoint lifetimes, so the compiler doesn't have to decide: it can allocate both to the same storage. Have you tried looking at this example in Compiler Explorer? This is a case we are taught *does* work for NRVO: every return is a simple variable name of the same type as the function's return, and their lifetimes are *non-overlapping* .
There is also a problem of const_cast. When you have const&&, you know it's an object which is going away so in principle you can cast the constness away and do whatever you want - it's perfectly fine. But if you allow implicit conversion from const& to const&&, the former can point to a true constant object (in a read-only memory) and casting the const away will explode.
If you follow functional programming techniques, you won't experience these problems. Because every method would be a pure function in which it would make no sense to declare a const& local variable and return it, because then all the code in between would be useless(pure functions cannot modify external state). Even in OO you would not do this because it violates single-responsibility principle. Also, in functional programming your classes will be immutable so data members would be declared const so that they could be public and there would be no need for getter's that return by value. So no temp lifetime extension problem. IMO this is not really a problem with the language, but rather just another reason to write better organized code.
Even with the proposed fix, we still would have all the dangling reference issues that I think it might not be worth the effort. Compared to Rust lifetime notation and borrow checking, this would be a very little fix to the language. C++ references might need a whole redesign.
void C::func() const&; WHEN ALONE is the same as void C::func(); Things change if you overload it like so; void C::func() const&; void C::func() const&&; C lvalue{}; lvalue.func(); // 1st overload, C object is an lvalue C{}.func(); // 2nd overload, C object is an rvalue
![Iterators and Ranges: Comparing C++ to D to Rust - Barry Revzin - [CppNow 2021]](http://i.ytimg.com/vi/d3qY4dZ2r4w/mqdefault.jpg)
![Iterators and Ranges: Comparing C++ to D to Rust - Barry Revzin - [CppNow 2021]](/img/tr.png)
![The Complete Guide to `return x;` - Arthur O'Dwyer - [CppNow 2021]](http://i.ytimg.com/vi/OGKAJD7bmr8/mqdefault.jpg)
This is a great language design talk.
My intuitive advice is to not make any more changes in the language around this topic. It will only create new problems and make learning C++ even longer. Whatever horrible state exists now is workable, as proven by successful projects. And it can be taught to motivated experts. If we add more stuff, even experts will just stop caring and will start just randomly changing code until it works. Sadly, most beginner programmers already do that very often.
On slide 14, the two variables of type A have disjoint lifetimes, so the compiler doesn't have to decide: it can allocate both to the same storage.
Have you tried looking at this example in Compiler Explorer? This is a case we are taught *does* work for NRVO: every return is a simple variable name of the same type as the function's return, and their lifetimes are *non-overlapping* .
There is also a problem of const_cast. When you have const&&, you know it's an object which is going away so in principle you can cast the constness away and do whatever you want - it's perfectly fine. But if you allow implicit conversion from const& to const&&, the former can point to a true constant object (in a read-only memory) and casting the const away will explode.
The problem is not in the way references binds.... the problem is in the assembly generated, it pushes all this shenanigans.
If you follow functional programming techniques, you won't experience these problems. Because every method would be a pure function in which it would make no sense to declare a const& local variable and return it, because then all the code in between would be useless(pure functions cannot modify external state). Even in OO you would not do this because it violates single-responsibility principle. Also, in functional programming your classes will be immutable so data members would be declared const so that they could be public and there would be no need for getter's that return by value. So no temp lifetime extension problem.
IMO this is not really a problem with the language, but rather just another reason to write better organized code.
Right, if you don't care about performance, functional programming is great
Okay, but you will run into new problems now
Even with the proposed fix, we still would have all the dangling reference issues that I think it might not be worth the effort. Compared to Rust lifetime notation and borrow checking, this would be a very little fix to the language. C++ references might need a whole redesign.
what is const & after method?
just the same that regular 'const' thing. you need to add '&' only if use that for other overload, like '&&' trailer thing
void C::func() const&; WHEN ALONE is the same as void C::func();
Things change if you overload it like so;
void C::func() const&;
void C::func() const&&;
C lvalue{};
lvalue.func(); // 1st overload, C object is an lvalue
C{}.func(); // 2nd overload, C object is an rvalue
I hate c++ so much. Everything has to have 10 cases and the most un intuitive possible