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.
Sutter’s Mill 
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?
https://pastebin.com/NHHFG0Na
Your comment system is broken…
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).
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.