Would this be helped by characterizing Expected/Outcome as something like ... "to be used as a resultant type by an operation which might fail" or some such? This would make all the arguments about what happens on assignment out of scope.
Thanks to your suggestion Robert to make Outcome a simple struct, assignment is now uncontroversial.
Of course now people would say the
scope is too narrow. etc..... The "reviews" of these ideas tend to try to generalize them - generally a good thing - but not always. Some times the attempt to reconcile all the requested features results in a watering down of the original good idea.
The v2 object is very considerably more simple than the v1 object. You may remember I converted over an existing codebase from v1 to v2, and for the most part it went okay. Expected is also much simpler than it was last May. Vicente took many of the same simplifying steps to Expected as I did to Outcome from the review.
When a simple idea like Outcome/Expected generates documentation of more than 4? pages, it's time to step back and ask oneself whether we've lost our and turned our original elegant idea into a monstrosity.
I know what you're saying. But when very senior members of WG21 seem to also need more than twenty pages of hand holding tutorial for a class which carries T|E and does nothing else, I think it's more a case of that the simpler and more fundamental the object, the vastly more documentation explaining it becomes needed. As an analogy, you may remember the "variant wars" which went on for nearly forever. A very simple, very well understood, object often generates the strongest opinions and people absolutely convinced that the other is wrong. Proof required to convince people thus rises accordingly. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/