The ISO C++ committee is here in Prague this week to finish C++20, and the meeting hosts Avast Software also arranged a great C++ meetup last night where over 300 people came out to see Bjarne Stroustrup, Tony Van Eerd, and me give talks. The videos are already online, see below — they’re really high quality, and it was a great event. Thank you again to everyone who came out to see us! You made us feel very welcome in your beautiful city and your enthusiasm for C++ is contagious (in a good way!).
Mine was a brand-new talk with material I’ve never presented on-camera before. (I gave a beta version at ACCU Autumn last November in Belfast.) I’m really excited about this upcoming work that I’m planning to bring to the committee in the near future, and I hope you enjoy it.
Thanks again to Hana Dusíková for her hard work organizing this meetup and this entire week-long record-shattering C++ standards meeting, by far the largest in history with 250 attendees. But there’s no rest for the competent — she still has to chair SG7 (reflection and compile-time programming) all day tomorrow. :) I’ll be there!
Sutter’s Mill 
You mentioned that time machine… Can’t you just use it and standardize this for C++11?
I see a usability trap with the implicit move on definite last use, though. If, after the definite last use, you add another use, it will silently change an untouched line from move to copy. Imho, it makes much more sense to enforce the std::move on last definite use, in combination with a use-after-move error (which can now be an error, not a warning if it’s passed as an in parameter).
What about on short term provide annotations to express intent so that a static analyzer can work its magic? Couldn’t that get us 75% of 30% by 2023 so we don’t have to wait 10 years. … Thanks for the lifetime safety. It is big thing that came out of 2020 that is not a part of 2020. If we could get a function_ref that can do object callbacks and rust traits or enough reflection emit to create them (15, Inheritance) and unified error handling (13, Error handling) and unified function call (103 Multiple ways to say the same thing), just end the never ending bifurcation and I can finally get some sleep at night. … I am not complaining but on a aside. Revert to CFront i.e. C with classes where there is a C analog for every C++ construct could go far. … I noticed all of your parameters in your talk could be T*. The language would be simpler if we allow replacing && with [intent] T*.
@Nicolas: Thanks!
@Petke: I hear you. :)
@bcs9: Yes, it’s fully compatible with calling existing functions. For example, an “in” parameter is simply treated as a const lvalue inside the function body for all purposes including for passing it onward to an existing overload set, except that the definite last use treats it as an rvalue (only if the actual argument is an rvalue) which naturally selects any rvalue overloads for the function it’s being passed to.
@RJ: Thanks, I think this has been fixed now.
@Matt: Right, so if you want to reuse the variable just make a local copy. (This is arguably already a good practice anyway for code clarity rather than reusing the by-value parameter directly.)
@Dan: Yes, the paper also mentions two kinds of return, which I didn’t have time to cover as this talk only had about an hour. I plan to cover return values and also the “this” parameter in the future when I have a 90-minute slot, likely at CppCon this autumn.
@Jiří: The nice thing is that if you want to declare a function that can take any kind of cv-qualified or l/r-value argument (which means it wants to read from it and possibly copy it), just declare “in” and write a single function. But yes you can additionally overload on these, and the compiler will select the best match based on the restrictions on the argument.
Your talk is a very interresting proposal. That would certainly simplify things.
However I am wondering about certain details of the “in” and “out” semantics with respect to library functions. If I understand it correctly, in can take const lvalue or rvalue reference. And out can take reference to either old constructed object or uninitialized memory. With multiple such parameters, the number of possible combinations grows. If the compiler sees the function definition, then it can generate variants on demand as it does with forwarding references. But what if the function is part of some library interface?
Does the library need to contain functions for all possible combinations of l/rvalue in and (un)initialized out parameters? Or is there some way to opt out from allowing rvalue references for some in parameters? Or am I completely wrong?
I really enjoyed your talk and I especially like the idea of specifying “what” in parameter passing instead of “how”.
I’m wondering if you’ve given any thought to returning values from functions/methods? For example, between moving the result vs “lending” a member via a reference.
Thank you. I enjoyed the talk and hope something like that comes to pass for passing. One quick issue with [in] parameters is often “by value” parameters that are modified, especially in math routines, as they not only act as parameters but also working storage/scratchpads. Using locals and lifetimes analysis could supplant that so it is just an optimisation issue I’d think, but it is something that is different to now and may trip up simplistic automated conversions.
The videos are marked as content made for kids. So it is not possible to save them to playlist and save to watch later.
I suspect that in a stable pure c++ context that would work rather well. But what about things like C APIs? Is there a viable incremental migration path? (What does Titus Winters have to say?) I’m also a bit concerned that there will be no indication at the call site which mode is being used. What pathologies will spring up from the callers assumptions and the function’s intentions not matching?
Great proposal. Hope it makes it into the standard some day. I think C++ might be a hoarder. Maybe it’s time for a spring cleaning, so that when the neighbours come and visit one won’t have to apologise for the mess.
Very nice talks! Thanks for the all great work!!!