[outcome v2] How important is it that an Expected implementation is also provided?
Dear list, I know it's been a fair few months since any news on Outcome v2. Ordinarily I'd be speaking at CppCon happening right now, but I instead chose Jens' Meeting C++ in November where I'll be speaking on Expected. Outcome v2 has undergone its period of maturation since it was completely rewritten to reflect peer review feedback last May. The new consensus design has fared very well after being put under heavy production use these last few months, and I expect it to return here for a second review before the end of this year. Outcome v2 will also be appearing in the WG21 October mailing, watch out for: * P0762R0: Concerns about `expected<T, E>` from the Boost.Outcome peer review * P0779R0: Proposing `operator try()` Outcome v2 currently implements the not published yet D0323R3 Expected proposal as part of its test suite as a refinement of what boost-dev thought Expected ought to be instead of what it is (ahem!). We run it against the Expected reference test suite, and it passes. So here's the question before any second peer review. Should Outcome v2 provide: 1. No Expected implementation at all, not even under a different name. Not its place. 2. The Expected implementation which the consensus on boost-dev felt the WG21 Expected ought to be (this is the current situation, and no we don't call it `expected<T, E>`). 3. A closely conforming, but not exactly conforming [1], implementation of WG21 Expected. Options 2 and 3 can be combined. But be aware that Peter rolled together an even more conforming Expected implementation using his variant2 library. I had been assuming people would be better advised to use his likely exactly conforming implementation, rather than Outcome v2's not exactly conforming implementation. Less surprise. Thoughts? Niall [1]: Known differences from P0323R3 `expected<T, E>` in this implementation: - `T` and `E` cannot be the same type. - No variant storage is implemented (note that technically speaking, D0323R3 does not require variant storage). -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
For those interested in giving it a whirl, the auto script converted "Boost edition" Outcome is now available at: https://github.com/ned14/boost-outcome Travis copies this into Boost and runs its test suite, so this Boostified edition is ready to go as a Boost library for a second review. There are no submodules in this converted edition, no external code at all, everything is Boost licensed. As per the last review feedback. What solely remains before it's ready for a second review is documentation. Anyone wishing to help out with writing the missing sections of https://ned14.github.io/outcome/ so it does not have unintelligible documentation like v1 Outcome did because I can't write tutorials anyone else can understand, please get in contact. Niall
2017-09-28 0:51 GMT+02:00 Niall Douglas via Boost <boost@lists.boost.org>:
So here's the question before any second peer review. Should Outcome v2 provide:
1. No Expected implementation at all, not even under a different name. Not its place.
2. The Expected implementation which the consensus on boost-dev felt the WG21 Expected ought to be (this is the current situation, and no we don't call it `expected<T, E>`).
3. A closely conforming, but not exactly conforming [1], implementation of WG21 Expected.
Options 2 and 3 can be combined. But be aware that Peter rolled together an even more conforming Expected implementation using his variant2 library. I had been assuming people would be better advised to use his likely exactly conforming implementation, rather than Outcome v2's not exactly conforming implementation. Less surprise.
Thoughts?
Just to clarify your question. Outcome v2 will provide a number of ways for the user to customize the interface: different templates, hooks, ability to derive from base templates and modify behavior. Correct? You are considering shipping Outcome v2 with one such customized type that resembles Expected as close as possible in order to: 1. Demonstrate that this is possible 2. Because many people will want to use a type they have learned from reading proposals for Expected. Right? Regards, &rzej;
Just to clarify your question. Outcome v2 will provide a number of ways for the user to customize the interface: different templates, hooks, ability to derive from base templates and modify behavior. Correct?
Customise the interface, no. Customise certain interoperation points, yes. Like when an outcome<T, EC, E> gets constructed into a result<T, EC>, you can specify how that should be per-namespace.
You are considering shipping Outcome v2 with one such customized type that resembles Expected as close as possible in order to: 1. Demonstrate that this is possible 2. Because many people will want to use a type they have learned from reading proposals for Expected.
It's already shipping an Expected implementation, but in its test suite purely so I can reuse Vicente's Expected test suite. Perhaps the FAQ entry might help? https://ned14.github.io/outcome/faq/#how-far-away-from-the-proposed-std-expe... But to answer your question, for v1 Outcome lots of people wanted an Expected implementation, not anything Outcome is doing. But v2 Outcome is much closer to Expected than before, and moreover the Expected proposal itself moved much closer to Outcome thanks to the Outcome v1 review. See https://github.com/viboes/std-make/blob/master/doc/proposal/expected/d0323r3... for just how much closer. I was just wondering how important an Expected implementation remains for people. Outcome v2's `unchecked<T, E>` and `checked<T, E>` are awfully close to Expected, as the draft WG21 paper comparing Outcome and Expected shows (https://groups.google.com/a/isocpp.org/d/msg/std-proposals/ynDjm5t1U_k/oYtlp...). Is it desirable that Outcome makes an Expected implementation a first tier type, or better to leave it to an FAQ entry like at present? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Le 04/10/2017 à 18:46, Niall Douglas via Boost a écrit :
It's already shipping an Expected implementation, but in its test suite purely so I can reuse Vicente's Expected test suite.
My implemtation is not so good to go to Boost ;-) Some of my test can be good, maybe others are not. In anycase I'm not sure they are sufficient :( Best, Vicente
It's already shipping an Expected implementation, but in its test suite purely so I can reuse Vicente's Expected test suite. My implemtation is not so good to go to Boost ;-) Some of my test can be good, maybe others are not. In anycase I'm not sure they are sufficient :(
I'm always very wary of trusting tests that I write myself. I consistently find that I end up missing things. A good test strategy is to use someone else's tests with a compatibility shim, it exercises parts I would never have thought of. BTW your test suite did find new bugs, but interestingly in one of the C++ compilers, not in Outcome :) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (3)
-
Andrzej Krzemienski -
Niall Douglas -
Vicente J. Botet Escriba