This video actually posted about two weeks ago, but… busy! Sorry.
Here it is, I hope you enjoy it. Note that as of this writing the Clang-based prototype implementation on Godbolt is not yet complete, in particular it still needs to implement out and forward parameters.
Published by Herb Sutter
Herb Sutter is an author and speaker, and a technical fellow at Citadel Securities. He serves as chair of the Standard C++ Foundation and its conference CppCon, and served as chair of the ISO C++ standards committee from 2002 to 2025.
View all posts by Herb Sutter
Published
4 thoughts on “My CppCon 2020 talk video is online”
You mentioned allowing ‘forward’ parameters to be used/read as const-lvalues. However, you don’t allow that for ‘out’ parameters. So, what happens if an ‘out’ parameter is forwarded? It seems that read access should bot be allowed in that case.
Hmm. So what about this:
void operator>>(inout std::istream stream, out Foo f);
If we fail to read a Foo from the stream, we may not want to write to f. So the requirement for “every path” doing something to f won’t be met? (It does seem like the standard library has been trying to encourage people to initialize f anyway lately, with operator>> for ints writing zero or min / max values since C++11.)
Anyway, is there a reason that “out” doesn’t *require* an uninitialized value (and disallow non-const lvalues)? (Assuming a valid way of making an initialized variable “uninitialized” in the outer scope).
First – I love it. It would be a huge simplification of the language. But I worry about the following:
void concat(vector &v, const string & o) {
for (auto&& a : v)
a += o;
}
void main() {
vector v = {“a”, “b”, “c”};
concat(v, v[1]); // oops – v[2] is wrong!
}
The above code is my biggest pet peeve with the recommendation to pass complex types as const references. I have seen this exact bug in the real world multiple times. If the new proposal can detect this and do the right thing, then wow! But I do worry that it may be very complicated for compilers to find. So to make it a question, how would changing this to in & out impact this code and would this bug potentially go away?
Sutter’s Mill 
You mentioned allowing ‘forward’ parameters to be used/read as const-lvalues. However, you don’t allow that for ‘out’ parameters. So, what happens if an ‘out’ parameter is forwarded? It seems that read access should bot be allowed in that case.
Hmm. So what about this:
void operator>>(inout std::istream stream, out Foo f);
If we fail to read a Foo from the stream, we may not want to write to f. So the requirement for “every path” doing something to f won’t be met? (It does seem like the standard library has been trying to encourage people to initialize f anyway lately, with operator>> for ints writing zero or min / max values since C++11.)
Anyway, is there a reason that “out” doesn’t *require* an uninitialized value (and disallow non-const lvalues)? (Assuming a valid way of making an initialized variable “uninitialized” in the outer scope).
https://pastebin.com/NHHFG0Na
Your comment system is broken…
Hey Herb,
First – I love it. It would be a huge simplification of the language. But I worry about the following:
void concat(vector &v, const string & o) {
for (auto&& a : v)
a += o;
}
void main() {
vector v = {“a”, “b”, “c”};
concat(v, v[1]); // oops – v[2] is wrong!
}
The above code is my biggest pet peeve with the recommendation to pass complex types as const references. I have seen this exact bug in the real world multiple times. If the new proposal can detect this and do the right thing, then wow! But I do worry that it may be very complicated for compilers to find. So to make it a question, how would changing this to in & out impact this code and would this bug potentially go away?