[outcome v2] How important is it that an Expected implementation is also provided?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[outcome v2] How important is it that an Expected implementation is also provided?

Boost - Dev mailing list
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/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

[outcome v2] Boostified Outcome ready for testing

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [outcome v2] How important is it that an Expected implementation is also provided?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
2017-09-28 0:51 GMT+02:00 Niall Douglas via Boost <[hidden email]>:

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [outcome v2] How important is it that an Expected implementation is also provided?

Boost - Dev mailing list
> 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-expected-t-e-is-outcome-s-checked-t-e

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.md
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_2PAgAJ).
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/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [outcome v2] How important is it that an Expected implementation is also provided?

Boost - Dev mailing list
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [outcome v2] How important is it that an Expected implementation is also provided?

Boost - Dev mailing list
>> 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/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost