220 34542 article Path: news.gmane.org!.POSTED!not-for-mail From: Niall Douglas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Feedback requested on D0762R0 draft 1: result and expected: Summary of the Boost.Outcome Date: Mon, 2 Oct 2017 16:16:33 -0700 (PDT) Lines: 367 Approved: news@gmane.org Message-ID: References: <1b0dc116-044e-4966-8c7b-aeadf0d1b300@isocpp.org> <59D2A087.6030907@gmx.net> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2861_1499511670.1506986193993" X-Trace: blaine.gmane.org 1506986197 23769 195.159.176.226 (2 Oct 2017 23:16:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 2 Oct 2017 23:16:37 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDGKFT5YZADRBUURZPHAKGQELTU5IYY@isocpp.org Tue Oct 03 01:16:32 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f72.google.com ([74.125.83.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dz9wq-0005Po-P4 for gclcip-std-proposals@m.gmane.org; Tue, 03 Oct 2017 01:16:29 +0200 Original-Received: by mail-pg0-f72.google.com with SMTP id u144sf783020pgb.2 for ; Mon, 02 Oct 2017 16:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=EnHA+Dt2qX4xHBqLZVNtjc1ET74TJMf9B9tiIEwBy40=; b=J8zog1sbJQG0yqt3HLzBaDHUYHuWczrgvQxJQAhilEJLJqpXv+TVsxvl5SH8TexVp1 6zE3ziIdffBDGeDcR+NM9/60dv5fgvi3jOMS/wSd5K4i6b5+BCc+uwZaoQmPxl2JNHNb OycI+4Puzmk96OL6blBWsFlh0QMsH5SlFKAF3Ft0ECWH7yJajLKoF9esb6EpZmvN1KmQ s48I2AqDVUGX85eU3HJDFAZhnL37a0LVvQ0wTm4Hf9AMvOygU6KgNWf3vWGiqNnypEwp waS63GNKK/NckkFdxAGdnde+trOomm/t+wKwXPtAUjMbjtVCnex9YW6q4PyIfTNyYW/L sReg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=EnHA+Dt2qX4xHBqLZVNtjc1ET74TJMf9B9tiIEwBy40=; b=bRQryIVAZV7PV8MmAqpe33xgJstz26wrnxBJgpXObrKgQbZx6RBa/xVSfZkGmcChdf mijTtcstS48KPgXHUpHhvYdPrbtKXXsAkk8AXtdWEJ5lbNIyudp3MNcDaRU5duaIl8Fe Yuex/bpiBkGmf7D3i1Af2NEffhYgeY366BcdBqNFrELDvkWuuTVnmMw+K19q22bU9Ecw LTHr2ycKcnLcsXCoybKcTJI2KNxna3m6bvOBV4jvaMehXBUAUSvDX59vz4zHHRkW/grq VzWl2e2POzXCDY7PrH5LC+55iJguesS7ayhhMV6ihn8o6wPYukOgv4Pe3RjjPZuKGN4W 3fKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=EnHA+Dt2qX4xHBqLZVNtjc1ET74TJMf9B9tiIEwBy40=; b=tcseMWxOfEQ0OZ8R3fMM9c8liNKExErCk42nZcKFob5zbqVpi3aSwB8AODOyCmA0Kk ETi37h9Xj5p6UJ5FHNpba0oIc6zBNdHT5F/ff0Qjkn8+eIcIevs66qI2Yw8PwSv192Q3 8lA3rS/coMiTgPABQ8ZzDw7vgdrIc72gKPEd3vHds6JE2rLK4TQOsvGbTHqoCtEF0evU PX3vteOlBlCoqmmzVlXwE8Zy64ASO2hq+Z6M2sgVjUgBcIX5jp5fww92jwUfQu+NFLlD jm+40VMQBMblYA0EmeQPay5NOLXJ1iH6Od13VuMGXCQfPc/OV2iGEjusqvjozIT0FwVE QFDQ== X-Gm-Message-State: AMCzsaXRt0UYeuaQHOTsdL3JOrKy5uHQS0QBzfmNfERi2EDfzBybLrXS HmiEQTceleUNyp9CGX07dIgKNQ== X-Google-Smtp-Source: AOwi7QBOoUlclWPl5W3KpgBDaVzrCK9jZen1BkfgC4JyY5i4yhDdSxJKS/BzIM5T4ZA2wDrw/Lnj+g== X-Received: by 10.159.59.92 with SMTP id j28mr1028260uah.26.1506986195864; Mon, 02 Oct 2017 16:16:35 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.86.25 with SMTP id y25ls746140uaa.7.gmail; Mon, 02 Oct 2017 16:16:34 -0700 (PDT) X-Received: by 10.31.167.75 with SMTP id q72mr681452vke.22.1506986194436; Mon, 02 Oct 2017 16:16:34 -0700 (PDT) In-Reply-To: <59D2A087.6030907@gmx.net> X-Original-Sender: nialldouglas14@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:34542 Archived-At: ------=_Part_2861_1499511670.1506986193993 Content-Type: multipart/alternative; boundary="----=_Part_2862_832418667.1506986193993" ------=_Part_2862_832418667.1506986193993 Content-Type: text/plain; charset="UTF-8" On Monday, October 2, 2017 at 9:24:43 PM UTC+1, Jens Maurer wrote: > > On 09/24/2017 03:55 AM, Niall Douglas wrote: > > D0762R0 draft 1: result and expected: Summary of the > Boost.Outcome peer review > > Thanks. > Firstly, thank you very much for taking the time to make such detailed commentary. I won't reply to the specifics as I received sufficient feedback on that edition of the paper that I was recommended to throw it away and try again for a third time at a complete rewrite. You should be aware that your feedback matched others on WG21, except you were much more polite about it. So thank you. I will however comment on the wider points you made, the ones which would apply to any paper I submit. > > I would appreciate a paragraph that introduces the whole topic of "T or > E". > Why would I need it at all? My guess is "consider a function that returns > a value T on success and otherwise some error indication E (which might be > an error_code or an exception type)". > It's a can of worms that one. I rewrote the tutorial for Outcome v1 three times, and still the Boost peer review panned it. My lousy attempts were that bad that Andrezj volunteered to write the v2 Outcome tutorial to keep me away from it, and you can see his work to date at https://ned14.github.io/outcome/tutorial/unchecked/ So I'll be honest, anything I write on that will be more confusing than if I wrote nothing. I'll defer to Vicente's earlier Expected papers for rationale. The version he's sending to the October mailing, BTW, is basically the final pre-LWG edition, it is now about implementation specifics, not rationale for the addition at all. > (Citing the std::filesystem library with its funny duplicate interface > functions may or may not be helpful.) > That's another can of worms which gets some people very angry indeed. I won't bore you with the details here. > > 1.2 item 10: "unexpected_type" seems to be a particularly obtuse > naming choice when reading the expression here. > That's Expected. Be aware that the Toronto meeting renamed it to `unexpected` now. And it's gained template deduction guides like Outcome has for `success` and `failure`. > > Regardless of whether E is constrained (similar to "result"), the behavior > prescribed in item 11 seems reasonable. Oh, and std::error_code has > an "ok" value; can we just return that instead of throwing > bad_result_access, > or is that too non-orthogonal? > Yeah, I'm actually in agreement on that. But the Boost peer review was not. Also, technically speaking, a default constructed error code is not an ok value. Nowhere in the standard does it actually guarantee that. Nor can it, because perhaps on some OS's system category the code 0 is not an ok value, and is in fact something very bad. (yes the standard is unhelpfully ambiguous on that, and it's why a constexpr null category would make so much more sense for a default initialised error code. Then we can *guarantee* that that is a "no error here" state) > > 2.1 "Result is specifically designed..." The argument then talks about > "compile-time overhead for variant storage with strong never-empty > guarantees" For someone not well-versed in the variant wars, could > you please explain (in the paper)? This is all templates in any case, > right? (also mentioned in 3.2) > I'll see what I can do about this. But even with explanation, some don't see the issue. Vicente for example thinks the compiler load for strong never empty variant storage to not be a problem. I say it does, but my proof is not the use of an Expected implementation, but rather when I wrapped std::variant into an Outcome which isn't the same thing because std::variant is really quite unusually hard on the compiler. And even then, it all depends on your personal weighting of the importance of lightweightness of interface files vs header files. And that encompasses a huge range of opinion, none of which is wrong per se. Though most on SG14 would tend in one direction on that. > > 2.2 second paragraph: "just use expected": We will either have > result or expected in the standard, not both, so "just use expected" > is not an option. And no, make_error_code(enum) should not usually > throw an exception; that would be very surprising (the > standard-provided functions are all noexcept). The third > argument is the compelling one ("the mapping from E to exceptions is > the task of some middle layer; if you don't like the default, > implement your own way of doing it"). This argument should be first. > Cool, thanks. > > One of Bjarne's concerns is "make it hard to ignore errors". How is > that reflected in either design, in particular for T=void? > Outcome is specifically designed to be used primarily in function returns, so it is able to make stronger assurances that errors cannot be easily ignored. Expected is specifically designed as a primitive on top of which you construct other stuff. That makes it hard to make such strong assurances. I personally speaking think that WG21 should standardise *layers* of implementation for these objects, not some one-size-fits-all single object like Expected which can never really deliver good practice on its own. But I'm told the committee don't want that. So the best I can do is submit a paper saying "please don't do X, Y and Z which the Boost peer review agreed to be a design mistake relative to other choices", and hope that what gets standardised doesn't wreck things too badly for future developments. The docs don't show it yet, but Outcome v2 is precisely such a layered design (so was v1, but different layers boost-dev didn't care for). You have: - unchecked - no runtime checking for correct usage at all - checked - throws bad_result_access_with or bad_result_access if used incorrectly - result - different default behaviours when used incorrectly depending on user's choice of type E - outcome - result but E carries payload P - outcome - result but can be T or EC or E or EC + E. This neatly sidesteps the std::filesystem loss-of-context API problem. All these have well defined interoperation semantics and strong ABI guarantees so big codebases can safely use Outcome in their public API. Indeed, C code can speak many of these objects, and Outcome provides a C macro API. Expected slots somewhere in between unchecked and checked because Expected has a wide value observer but narrow observers for everything else which I find to be a severe design mistake which nobody should consider after the Optional experience. But clearly a majority on WG21 do not agree with me. > > In short, I'm glad to learn that the differences between expected > and result are fairly small, once expected moves away from the > misguided emulation of std::optional (with operator* and friends). > > If Expected looked like unchecked from Outcome, I'd consider that a great foundation stone on top of which to build other stuff. Though perhaps a bit too simple to be used on its own. But all that said, this stuff can be Conceptualised into generic constructs and logic, and that ought to be the long term goal for all this stuff with us taking a least risk approach to threatening that right now. Vicente has some early ideas on that, I won't share them here, but they are quite thought provoking. Niall -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/aebb6cf4-7095-4258-8868-d6eaf287ddd4%40isocpp.org. ------=_Part_2862_832418667.1506986193993 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, October 2, 2017 at 9:24:43 PM UTC+1, Jens Maure= r wrote:
On 09/24/2017 03:55 AM= , Niall Douglas wrote:
> D0762R0 draft 1: result<T, E> and expected<T, E>: Summ= ary of the Boost.Outcome peer review

Thanks.

Firstly, thank you very much for takin= g the time to make such detailed commentary. I won't reply to the speci= fics as I received sufficient feedback on that edition of the paper that I = was recommended to throw it away and try again for a third time at a comple= te rewrite. You should be aware that your feedback matched others on WG21, = except you were much more polite about it. So thank you.

I will however comment on the wider points you made, the ones which = would apply to any paper I submit.
=C2=A0

I would appreciate a paragraph that introduces the whole topic of "= ;T or E".
Why would I need it at all? =C2=A0My guess is "consider a function= that returns
a value T on success and otherwise some error indication E (which might= be
an error_code or an exception type)".

It's a can of worms that one. I re= wrote the tutorial for Outcome v1 three times, and still the Boost peer rev= iew panned it. My lousy attempts were that bad that Andrezj volunteered to = write the v2 Outcome tutorial to keep me away from it, and you can see his = work to date at=C2=A0https://ned14.github.io/outcome/tutorial/unchecked/

So I'll be honest, anything I write on that will= be more confusing than if I wrote nothing. I'll defer to Vicente's= earlier Expected papers for rationale. The version he's sending to the= October mailing, BTW, is basically the final pre-LWG edition, it is now ab= out implementation specifics, not rationale for the addition at all.
<= div>=C2=A0
(Citing the st= d::filesystem library with its funny duplicate interface
functions may or may not be helpful.)

That's another can of worms which = gets some people very angry indeed. I won't bore you with the details h= ere.
=C2=A0
1.2 item 10: "unexpected_type" seems to be a particularly obtuse
naming choice when reading the expression here.

That's Expected. Be aware that the= Toronto meeting renamed it to `unexpected<E>` now. And it's gain= ed template deduction guides like Outcome has for `success<T>` and `f= ailure<E>`.
=C2=A0

Regardless of whether E is constrained (similar to "resu= lt"), the behavior
prescribed in item 11 seems reasonable. =C2=A0Oh, and std::error_code h= as
an "ok" value; can we just return that instead of throwing ba= d_result_access,
or is that too non-orthogonal?

Yeah, I'm actually in agreement on= that. But the Boost peer review was not.

Also, te= chnically speaking, a default constructed error code is not an ok value. No= where in the standard does it actually guarantee that. Nor can it, because = perhaps on some OS's system category the code 0 is not an ok value, and= is in fact something very bad.

(yes the standard = is unhelpfully ambiguous on that, and it's why a constexpr null categor= y would make so much more sense for a default initialised error code. Then = we can guarantee=C2=A0that that is a "no error here" state= )
=C2=A0

2.1 "Result is specifically designed..." The argument then ta= lks about
"compile-time overhead for variant storage with strong never-empty
guarantees" For someone not well-versed in the variant wars, could
you please explain (in the paper)? =C2=A0This is all templates in any c= ase,
right? =C2=A0(also mentioned in 3.2)

I'll see what I can do about this.= But even with explanation, some don't see the issue. Vicente for examp= le thinks the compiler load for strong never empty variant storage to not b= e a problem. I say it does, but my proof is not the use of an Expected impl= ementation, but rather when I wrapped std::variant into an Outcome which is= n't the same thing because std::variant is really quite unusually hard = on the compiler.

And even then, it all depends on = your personal weighting of the importance of lightweightness of interface f= iles vs header files. And that encompasses a huge range of opinion, none of= which is wrong per se. Though most on SG14 would tend in one direction on = that.
=C2=A0

2.2 second paragraph: "just use expected": We will either hav= e
result or expected in the standard, not both, so "just use expecte= d"
is not an option. =C2=A0And no, make_error_code(enum) should not usuall= y
throw an exception; that would be very surprising (the
standard-provided functions are all noexcept). =C2=A0The third
argument is the compelling one ("the mapping from E to exceptions = is
the task of some middle layer; if you don't like the default,
implement your own way of doing it"). =C2=A0This argument should b= e first.

Cool, thanks.
=C2=A0

One of Bjarne's concerns is "make it hard to ignore errors&quo= t;. =C2=A0How is
that reflected in either design, in particular for T=3Dvoid?

Outcome is specifically designed to be= used primarily in function returns, so it is able to make stronger assuran= ces that errors cannot be easily ignored.

Expected= is specifically designed as a primitive on top of which you construct othe= r stuff. That makes it hard to make such strong assurances.

<= /div>
I personally speaking think that WG21 should standardise layer= s=C2=A0of implementation for these objects, not some one-size-fits-all = single object like Expected which can never really deliver good practice on= its own. But I'm told the committee don't want that. So the best I= can do is submit a paper saying "please don't do X, Y and Z which= the Boost peer review agreed to be a design mistake relative to other choi= ces", and hope that what gets standardised doesn't wreck things to= o badly for future developments.

The docs don'= t show it yet, but Outcome v2 is precisely such a layered design (so was v1= , but different layers boost-dev didn't care for). You have:
=
  • unchecked<T, E> - no runtime checking for corr= ect usage at all
  • checked<T, E> - throws bad_result_access_wit= h<E> or bad_result_access if used incorrectly
  • result<T, E&= gt; - different default behaviours when used incorrectly depending on user&= #39;s choice of type E
  • outcome<T, E, P> - result but E carrie= s payload P
  • outcome<T, EC, E> - result but can be T or EC or = E or EC + E. This neatly sidesteps the std::filesystem loss-of-context API = problem.
All these have well defined interoperation semantics= and strong ABI guarantees so big codebases can safely use Outcome in their= public API. Indeed, C code can speak many of these objects, and Outcome pr= ovides a C macro API.

Expected slots somewhere in = between unchecked<T, E> and checked<T, E> because Expected has = a wide value observer but narrow observers for everything else which I find= to be a severe design mistake which nobody should consider after the Optio= nal experience. But clearly a majority on WG21 do not agree with me.
<= /div>
=C2=A0

In short, I'm glad to learn that the differences between expected
and result are fairly small, once expected moves away from the
misguided emulation of std::optional (with operator* and friends).

If Expected looked like unchecked<T, E> from Ou= tcome, I'd consider that a great foundation stone on top of which to bu= ild other stuff. Though perhaps a bit too simple to be used on its own.

But all that said, this stuff can be Conceptualised i= nto generic constructs and logic, and that ought to be the long term goal f= or all this stuff with us taking a least risk approach to threatening that = right now. Vicente has some early ideas on that, I won't share them her= e, but they are quite thought provoking.

Niall

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/aebb6cf4-7095-4258-8868-d6eaf287ddd4= %40isocpp.org.
------=_Part_2862_832418667.1506986193993-- ------=_Part_2861_1499511670.1506986193993-- .