220 34549 <1f550260-377a-4409-b29e-dee0769d6bd9@isocpp.org> 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: Tue, 3 Oct 2017 08:21:33 -0700 (PDT) Lines: 131 Approved: news@gmane.org Message-ID: <1f550260-377a-4409-b29e-dee0769d6bd9@isocpp.org> References: <1b0dc116-044e-4966-8c7b-aeadf0d1b300@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6957_113859296.1507044093620" X-Trace: blaine.gmane.org 1507044096 17230 195.159.176.226 (3 Oct 2017 15:21:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Oct 2017 15:21:36 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDGKFT5YZADRB7WVZ3HAKGQESKVP5TY@isocpp.org Tue Oct 03 17:21:31 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f198.google.com ([209.85.216.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzP0i-0003lv-5U for gclcip-std-proposals@m.gmane.org; Tue, 03 Oct 2017 17:21:28 +0200 Original-Received: by mail-qt0-f198.google.com with SMTP id 53sf5150510qtz.21 for ; Tue, 03 Oct 2017 08:21: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=9FUn0M+pLnCsfVnQt8D8oLDU2fUrCpN2VA1qITg101g=; b=sigzU90/UDl7iDiKFra5etmOIj/iF/CD2IHDdKzm7sfmYkXCNYAzCZ4VWVvwpi0/tm ek0764bS1ms7Ia2nldX6RXDRgNcjwPq52HLros/pdYTwD3/+fUKvxBLIqZe9F28y73rC TvBTWuzlZkeT7kHCAQQKEYTWBYCNRtsaQD8NG5+Pf1Pek9T/YOYWjL11n9wo5JFvbRpM Sn14tCzKRvs5mSMFm7sfX2H4ZNet8mI1BFd6dnfLimmCPwVYJ0+zeAIBFvwtWp2CuKc0 VuXGhRu6hpAxOgbs/LKgeTLFd6P0kpxg7VC883XeOk5dlA0lOJ7a3dNN87Zg7jPpv+BQ feQw== 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=9FUn0M+pLnCsfVnQt8D8oLDU2fUrCpN2VA1qITg101g=; b=jUc+8eMidFpvXwG6hmACCuOya9khawncOJf3XVPNmYmV84ZPXBjkfpDgJdbOemBcBS wAfTbQ2kdCIYl+A5bhavv1fpN9udgM3ubOInmuxkyUD3ppsN0Rh/WWk5k+kzqbRllCIg yJrxy4JKAfn+Vi3waL+GLeweiF40RE4W3DFtmkfaKfHU95+TBXN2BMOjf2xCbxHXH573 u0uKFeXwYNM0elu7VVHVhuhPyX7zTpMMk1KktpFo1+YIW4tUFDw/rg3vZkSL8WZoNITK uuGOTu9Md/AAm+U+1ifsv3LR4OY5C3kPdxSPXr3BFiunxFsQEvbpAlLTpIm+euyq/RRL dYyQ== 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=9FUn0M+pLnCsfVnQt8D8oLDU2fUrCpN2VA1qITg101g=; b=Xk67ttCqWqESxG4aX0TIj/T+ccqdwWeU2HSwKYRCXtEO/moma5m1n962NQuKWkyW15 qTsxaY9aYx5ddBdhDQG4ls4q2v6tUKKdjxJJv8ZmTZE5ulnIKGSmT2y9wsPct1x9DCtO TQsI/LCFxv0R2UZa0Ps1r/hMyKI8krexXeLTjPP/r7E0Wzt4utjfDlFuPW59/1xCowFU M1jq2IBlNTEwwxdKO/ZLhunp1UIARzsZrNAWaSE3mbSHDnOpj2idlsW9j0JaJ3aV5s7h ZEmyymsLFHRYlpM3WCBDzQnsMWH2ziTx/8v8NRqXFy67jb+1RYsWRA/kqCdwp/LidC9j Z5/A== X-Gm-Message-State: AMCzsaWpgfQ1bPZeesB9WW/Vo29l9YGxzCbUdmdkpOE0t9qp4F0TVLBu q4/PGcluPLLo4Wv7htcoHTvBLg== X-Google-Smtp-Source: AOwi7QCo8R7b1vLjnfpUx5uQNgJXwR67igu/XRTbvt0een/uup6Jt61RpEljGNdx/lzbKBwO8Rt5UA== X-Received: by 10.31.49.134 with SMTP id x128mr3837533vkx.48.1507044095581; Tue, 03 Oct 2017 08:21:35 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.74.140 with SMTP id s12ls4454014uae.20.gmail; Tue, 03 Oct 2017 08:21:34 -0700 (PDT) X-Received: by 10.31.218.3 with SMTP id r3mr807200vkg.28.1507044094263; Tue, 03 Oct 2017 08:21:34 -0700 (PDT) In-Reply-To: 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:34549 Archived-At: ------=_Part_6957_113859296.1507044093620 Content-Type: multipart/alternative; boundary="----=_Part_6958_1207466558.1507044093620" ------=_Part_6958_1207466558.1507044093620 Content-Type: text/plain; charset="UTF-8" > > > Yet another reason to prefer `expected`: it doesn't encourage you to use > poor interfaces. > A lot of these sweeping hand waving generalisations of yours unfortunately seem to repeatedly come from ignorance. It's hardly the first time you've made these unfounded claims, and you did so repeatedly throughout your reply. Outcome's checked is very similar to expected. Do your research before making more claims without basis. > > `Result` uses "variant storage" just as much as `Expected`. > Outcome uses struct storage, not union storage. > > And a strong never empty guaranteed variant storage like Expected provides >> means a ton load more again implementation code, much of which is complex >> for the compiler to instantiate i.e. lots of SFINAE and concept matching. >> You've got potential double buffering in there, >> > > P0110 shows that you don't have to double-buffer to get the strong never > empty guarantee. The proposal already requires, if you do > assignment/emplacement, that `E` is nothrow move constructible. That allows > you to avoid double buffering. > > That's not to say that the code isn't complex. But there is no potential > for double buffering. > D0323R3 currently entirely deletes assignment unless E is nothrow move constructible, thus allowing avoidance of having to consider double buffering. > > The moment the standard starts requiring a specific implementation is the > moment it stops being a standard and starts being an implementation of some > standard. The committee doesn't "historically" dictate implementations > because *it's not their job*. > > Things change as standard libraries grow. 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/1f550260-377a-4409-b29e-dee0769d6bd9%40isocpp.org. ------=_Part_6958_1207466558.1507044093620 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Yet another reason to prefer `expected`: it doesn&#= 39;t encourage you to use poor interfaces.
A lot of these sweeping hand waving generalisations of yours un= fortunately seem to repeatedly come from ignorance. It's hardly the fir= st time you've made these unfounded claims, and you did so repeatedly t= hroughout your reply.

Outcome's checked<T, = E> is very similar to expected<T, E>. Do your research before maki= ng more claims without basis.
=C2=A0

`Result` uses &q= uot;variant storage" just as much as `Expected`.

Outcome uses struct storage, not union storage.<= /div>
=C2=A0

And a strong never empty guaranteed variant storage= like Expected provides means a ton load more again implementation code, mu= ch of which is complex for the compiler to instantiate i.e. lots of SFINAE = and concept matching. You've got potential double buffering in there,

P0110 shows that you don't h= ave to double-buffer to get the strong never empty guarantee. The proposal = already requires, if you do assignment/emplacement, that `E` is nothrow mov= e constructible. That allows you to avoid double buffering.

<= /div>
That's not to say that the code isn't complex. But there = is no potential for double buffering.

=
D0323R3 currently entirely deletes assignment unless E is nothro= w move constructible, thus allowing avoidance of having to consider double = buffering.
=C2=A0

The moment the stand= ard starts requiring a specific implementation is the moment it stops being= a standard and starts being an implementation of some standard. The commit= tee doesn't "historically" dictate implementations because it's not their job.

Things change= as standard libraries grow.

Niall=C2=A0

--
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/1f550260-377a-4409-b29e-dee0769d6bd9= %40isocpp.org.
------=_Part_6958_1207466558.1507044093620-- ------=_Part_6957_113859296.1507044093620-- .