220 35854 <260797cb-896d-4386-a2c7-1212d73f1884@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Output parameters Date: Sun, 10 Dec 2017 10:40:44 -0800 (PST) Lines: 280 Approved: news@gmane.org Message-ID: <260797cb-896d-4386-a2c7-1212d73f1884@isocpp.org> References: <1c1bb50b-2d59-4247-a158-158065fb1a9a@isocpp.org> <0c471d5c-b9b2-40f9-a2bf-908edbb1f272@isocpp.org> <17e3b13c-eb1b-fc2c-590e-3d394f164f9a@wanadoo.fr> <1c8e3ec4-6c5f-43db-bb6e-131d725f7ba4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_165_351678291.1512931244137" X-Trace: blaine.gmane.org 1512931244 20618 195.159.176.226 (10 Dec 2017 18:40:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 10 Dec 2017 18:40:44 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBLP7WXIQKGQE3K2I3ZA@isocpp.org Sun Dec 10 19:40:40 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f198.google.com ([209.85.217.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eO6Wm-0005B0-5N for gclcip-std-proposals@m.gmane.org; Sun, 10 Dec 2017 19:40:40 +0100 Original-Received: by mail-ua0-f198.google.com with SMTP id v15sf10661522uae.23 for ; Sun, 10 Dec 2017 10:40:47 -0800 (PST) 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=niPU0FA0v4I9xhlgaIn5kOzJpOoOLwpn+WWizLsR+gE=; b=R5O2/HRrN+yITOaNjqhA9IntrT4YtIEkoaVtEevZqSZmIcZlvMrEul3XjBhxjopvl3 ijs6AJy3XM2eIOKfov3FGoQ/bUhBMOKlkOlOiUPDSic9rYUby2F1hbxz7jGk4KLV5Ox6 r927NIZr84mYczUjDb2l473OKr7o22J+37ENS/ni+s6pu53huTvgrNsEszaxNZHnnb7B hQiNcmoEnxUYgQ0Ac+Oz8vD7EYQ2zRRpcA3C0E+EfLLEu9bGO35/JnXAdEqRm/Y1hXZh mNVCqijdIIO/uy8zG/IuWcXxelenzrd9Uwl6NO2GZWz5VlGIcJ58/s5H/X4bAr6VQTk3 vaZA== 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=niPU0FA0v4I9xhlgaIn5kOzJpOoOLwpn+WWizLsR+gE=; b=BQJJc+suMriD+pSyuR+YDnQkIAcmoE3K+cIcGWpF4ifNcbUQDLrtIxhLwJW+lsbuZQ Oz3AnC/6HUwAhI1gJv97WyZp1o1AE49KiY1pG48cyJO924DA2QwxKRXlXv5njhWgtQso SL+GExhWBJ7Q2r1PX8b1p5l9ogpLOalzMMYmWvGcC1vr1323HYXxw5rmCwrk5xe5E95U Po/ygimvJ+MhAA7R7qkOU6Atwt6OTML+JRv+g31+7+5mMYbY8EPg0yUAEE5Ss/pvNX5Q /MvQSsmxbZun4M2JVSN94L9IIbaMX9oCC+IHtj6wMtlzZd+Z0IdLZ8JWzuySazWoL2MF iZ1g== 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=niPU0FA0v4I9xhlgaIn5kOzJpOoOLwpn+WWizLsR+gE=; b=Kvh8Xuz+Hzu+cRBTF//29X3nyj3AZaV7x4z626Js7LjWRYEPYyUrnn+gmMOcJ8gg50 RdBN1eH1mgwbti2Ntg0ACluRshCrDEYVgnp274W/VGhoCj+Z6pT6AHPFYAgjwR93Hwy5 Mh1fBuYdDsk7++mItr0vc8qRUlG60/GBwPdYcYHx6JzkTWWlgYC50qFSHDmgyWlI9Lul pfaxOJQnsDi3K4jWq5cyDQG6WILhDK3Y6ym6k0Ydlvd2PV8kW0ZnQTb0s9DFiTR6D0ky bglqcxAr9sFpxyRidUtgKkPLnDjrk8nrvPWo41Ghzr9hdrzofpuVB0tjoVHYEk+V0r0l 4bqw== X-Gm-Message-State: AKGB3mLCzB+cWZCRwFOnLdC39CRDf5cFgrlRW/rgrhVm5MWV+mdgenJn F9N+JDL/FQCC6LrB15rUs0KDmg== X-Google-Smtp-Source: AGs4zMbvChdasfcuNOnrhpyuJhLF5cT7L4v9qsoKIGlC4VjZ+D+E1FEh1XILM//MGU6T2KkuJ4T9Sg== X-Received: by 10.176.11.9 with SMTP id b9mr10246547uak.105.1512931246985; Sun, 10 Dec 2017 10:40:46 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.95.34 with SMTP id p34ls2014630uah.5.gmail; Sun, 10 Dec 2017 10:40:45 -0800 (PST) X-Received: by 10.31.2.148 with SMTP id 142mr1925344vkc.1.1512931244731; Sun, 10 Dec 2017 10:40:44 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@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:35854 Archived-At: ------=_Part_165_351678291.1512931244137 Content-Type: multipart/alternative; boundary="----=_Part_166_260512758.1512931244137" ------=_Part_166_260512758.1512931244137 Content-Type: text/plain; charset="UTF-8" On Sunday, December 10, 2017 at 12:48:09 PM UTC-5, Jake Arkinstall wrote: > > One-off return types often occur... the first time you use them. Then, the > next time you use them, which is often the case later down the line, you're > tied to using whatever approach you used the first time unless you want to > either be inconsistent or introduce breaking changes. > > I think of this as a DRY-trap. If you are to keep repeated code to a > minimum, you need to make decisions early on such that you don't end up > forced into repeating code. For example, with strictly output parameters, > you need to create those variables before the function is called (and if > you call this function in several places, this means repeating). If you > want to use an unnamed struct, you have to do the same thing unless you > auto it out (but then you might as well just name that struct and be done > with the matter). > > This argument only applies to the justification "it's only used once". > There are other justifications, such as resource usage (covered by > Vincente) and scope control (*{ cheap a; {expensive b; do_something(a,b); > handle_b(b); } use_lots_of_resources(); handle_a(a); } *) for which I > have no rebuttal. They're completely valid. > I'm trying to understand this use case. You have a function which returns two values: one is "cheap" and the other is "expensive". Therefore, the caller* may* want to give the "expensive" one a shorter lifetime. Note that the caller is not* required* to do so; such a user simply might want to. In order for this to matter, "expensive" would have to be expensive in terms of stack space. If it were simply "expensive" in terms of dynamic storage (containers), then you could simply remove the data from `expensive` (move it into a temporary, for example). So here's a narrow list of elements needed for this to come up: 1. The function returns an object of sufficient size that callers may want to get rid of it as soon as conditions permit. 2. The function returns multiple values, at least one of which is the aforementioned gargantuan object. 3. The multiple return values are sufficiently unrelated that they could reasonably have different lifetimes. That is, it is reasonable to use the non-gargantuan object even after the gargantuan object is gone. This is a subset-of-a-subset-of-a-subset. I can't think of a circumstance where this would happen. The closest thing I can come up with here is something like `expected`, where the other return value is something like an error code. But here, you're talking about divergent code paths, since `expected` is a sum type, not a product type. Just because a use case is "valid" doesn't mean we need special language to support it. If the valid use case is not particularly common, we can just use the existing tools to handle it. The default mechanism should be to use return values and structs; if there is some overriding concern in a* specific* case, then we always have the option to take references. Ugly solutions for unusual circumstances are fine. Lastly, if `cheap` truly is "cheap", then there's nothing stopping you from doing this: cheap a; { auto [c, b] = do_something(); handle_b(b); a = c; } It may not be the most optimal solution possible, but it gets the job done. And it retains *all* of the advantages of a struct-based solution. Indeed, we may someday allow structured binding to directly assign the decomposed subobjects to existing objects. That would remove the need to use a different name and the `a = c` part. So all you would be left with is the overhead of one return value that never gets used after it gets assigned. I think we can live with that. I'd sooner go for a proposal that somehow adds some fairy dust to make > returning equally as effective in these outlying cases, than one which > standardises (and thus legitimizes) use of out parameters for the > foreseeable future. Though if the former is even possible, whoever comes up > with it should probably prepare to receive a lot of hate mail from compiler > writers. > The reason we have structured binding for multiple return values is because that doesn't require making changes to the basic ABIs used for communicating between functions. The kind of "fairy dust" you're talking about would probably require such changes; a function that uses this syntax will need an entire new way of communicating though ABIs. That's going to be a hard sell, especially since the best motivation thus far is a corner case. -- 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/260797cb-896d-4386-a2c7-1212d73f1884%40isocpp.org. ------=_Part_166_260512758.1512931244137 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, December 10, 2017 at 12:48:09 PM UTC-5, Jake Ar= kinstall wrote:
One-off return types often = occur... the first time you use them. Then, the next time you use them, whi= ch is often the case later down the line, you're tied to using whatever= approach you used the first time unless you want to either be inconsistent= or introduce breaking changes.

I think of this as a DR= Y-trap. If you are to keep repeated code to a minimum, you need to make dec= isions early on such that you don't end up forced into repeating code. = For example, with strictly output parameters, you need to create those vari= ables before the function is called (and if you call this function in sever= al places, this means repeating). If you want to use an unnamed struct, you= have to do the same thing unless you auto it out (but then you might as we= ll just name that struct and be done with the matter).

= This argument only applies to the justification "it's only used on= ce". There are other justifications, such as resource usage (covered b= y Vincente) and scope control ({=C2=A0cheap a; {expensive b; do_somethin= g(a,b); handle_b(b); } use_lots_of_resources(); handle_a(a); } ) for wh= ich I have no rebuttal. They're completely valid.

I'm trying to understand this use case.

You have a function which returns two values: one is= "cheap" and the other is "expensive". Therefore, the c= aller may want to give the "expensive" one a shorter lifet= ime. Note that the caller is not required to do so; such a user simp= ly might want to.

In order for this to matter, &qu= ot;expensive" would have to be expensive in terms of stack space. If i= t were simply "expensive" in terms of dynamic storage (containers= ), then you could simply remove the data from `expensive` (move it into a t= emporary, for example).

So here's a narrow lis= t of elements needed for this to come up:

1. The f= unction returns an object of sufficient size that callers may want to get r= id of it as soon as conditions permit.
2. The function returns mu= ltiple values, at least one of which is the aforementioned gargantuan objec= t.
3. The multiple return values are sufficiently unrelated that = they could reasonably have different lifetimes. That is, it is reasonable t= o use the non-gargantuan object even after the gargantuan object is gone.

This is a subset-of-a-subset-of-a-subset. I can'= ;t think of a circumstance where this would happen. The closest thing I can= come up with here is something like `expected<expensive, cheap>`, wh= ere the other return value is something like an error code. But here, you&#= 39;re talking about divergent code paths, since `expected` is a sum type, n= ot a product type.

Just because a use case is &quo= t;valid" doesn't mean we need special language to support it. If t= he valid use case is not particularly common, we can just use the existing = tools to handle it. The default mechanism should be to use return values an= d structs; if there is some overriding concern in a specific case, then we always have the = option to take references.

Ugly solutions for unusual circumstanc= es are fine.

Lastly, if `cheap= ` truly is "cheap", then there's nothing stopping you from do= ing this:

<= span class=3D"styled-by-prettify" style=3D"color: #000;">cheap a;
{
=C2=A0 auto [c= , b= ] =3D do_something();
=C2=A0 handle_b(b);
=C2=A0 a =3D c= ;
}
<= /code>

It may not be the most optimal solution pos= sible, but it gets the job done. And it retains all of the advantage= s of a struct-based solution.

Indeed, we may somed= ay allow structured binding to directly assign the decomposed subobjects to= existing objects. That would remove the need to use a different name and t= he `a =3D c` part. So all you would be left with is the overhead of one ret= urn value that never gets used after it gets assigned.

=
I think we can live with that.

I'd sooner go for a proposal that somehow= adds some fairy dust to make returning equally as effective in these outly= ing cases, than one which standardises (and thus legitimizes) use of out pa= rameters for the foreseeable future. Though if the former is even possible,= whoever comes up with it should probably prepare to receive a lot of hate = mail from compiler writers.

The reason we have structured binding for multiple return values is = because that doesn't require making changes to the basic ABIs used for = communicating between functions. The kind of "fairy dust" you'= ;re talking about would probably require such changes; a function that uses= this syntax will need an entire new way of communicating though ABIs.

That's going to be a hard sell, especially since t= he best motivation thus far is a corner case.

--
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/260797cb-896d-4386-a2c7-1212d73f1884= %40isocpp.org.
------=_Part_166_260512758.1512931244137-- ------=_Part_165_351678291.1512931244137-- .