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 
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?