220 18238 <93b6196f-32be-4683-a736-cca5dbc02b83@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Core Language feature: Multiple assignments from multiple return values via tuple Date: Wed, 27 May 2015 08:11:00 -0700 (PDT) Lines: 225 Approved: news@gmane.org Message-ID: <93b6196f-32be-4683-a736-cca5dbc02b83@isocpp.org> References: <69a59613-6504-466a-9878-786653d6087f@isocpp.org> <4498da2a-af3a-457d-9bf7-e8bb3721d6b9@isocpp.org> <6ea4a1dc-bfb4-4219-93ea-606619a77c53@isocpp.org> <71a799fc-1897-4c43-adc6-5d26267688bb@isocpp.org> <500d24fe-73ba-439a-ac53-aeaa7919111e@isocpp.org> <32801228-1faf-4b73-8da1-9c8ce5bcb9ae@isocpp.org> <0b91248a-1994-4127-932e-9e1d97edadb2@isocpp.org> <62FE5462-BE3F-4C9E-B03D-322CB0CFF753@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_583_703389892.1432739460260" X-Trace: ger.gmane.org 1432739463 5734 80.91.229.3 (27 May 2015 15:11:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 May 2015 15:11:03 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBBF5S6VQKGQEDG2UKQY@isocpp.org Wed May 27 17:11:03 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f72.google.com ([209.85.220.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yxcz0-0004lN-Ov for gclcip-std-proposals@m.gmane.org; Wed, 27 May 2015 17:11:03 +0200 Original-Received: by pacyx8 with SMTP id yx8sf25215pac.0 for ; Wed, 27 May 2015 08:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=PTOnDZWiC56hwr/adAuhNO0mnFS1Ah4bkqtfVFJNr8k=; b=BCu9a+nGkP77D2NPYKn0N1VvMEBRqJXuWTvCRJz2X9TLaKLAKlFgBjhgnv/TN6E4SW t5s0XKb2uTGrEdorGdHq2ZO8Gh1yiIzqGD/fXjTHXUxL0ZbOj8VbAoMNlv14vUtZ7PJc +ipJuBgpyWbirxGzwktyTFwXCh+jlBpzH0CxWxtiMhMjG/bXo8cWZh3thACJeuUy0w2f 92fWZjS3MsEr7hoPu44mKyyA1xhWb9jIj4i3O54EtF9B5kO3W2EHfoLC8yv/OYbwONIG 6OghuUk+dwmFW4no/Ah4fwBeStT+/SLeO/AX0nODBxe4QPT5nI2NBvvFRi1vgMN8BaIp v3vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=PTOnDZWiC56hwr/adAuhNO0mnFS1Ah4bkqtfVFJNr8k=; b=JGVIm3ulu0Y0+t2dKNHBTsDkA5MuicYax7Vgj+Elwnyloi2TzqEA/kWnPnYCsvOWDl ITDW4uRUTPhKv7q9WwYRPFalnKqNL6M3439MTvVgNt9AdUzWV2u+0ktq3ff1l2pQj+uD 7ThT+u3p0ZJwKwVsdp/O4UVUFE1qQfoS7xJpjZS+Svr/kHOyHyc43rZSKTad7w4Nd/2e ptf64iCOuPI+MadLaqFqbR4JNswEb3kkTCK007DXgPd0EiNBCwUXGh2htVeSbR/M3d65 D0vWb5EYjTVb7yWtYh1MJEC6atnVISHqcZImCb615l4KTE5k+Tycp7AGygOfz6FwgwNn bJig== X-Gm-Message-State: ALoCoQmcAn+I7A5qIqH+zZ4ImJsZliXFflwg5OReD3LfnpC/jTcJX0M4oRwtF4AsBy7r+a2Yx9lE X-Received: by 10.70.118.99 with SMTP id kl3mr41027627pdb.12.1432739461623; Wed, 27 May 2015 08:11:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.22.69 with SMTP id 63ls245520qgm.5.gmail; Wed, 27 May 2015 08:11:00 -0700 (PDT) X-Received: by 10.140.21.111 with SMTP id 102mr392379qgk.4.1432739460697; Wed, 27 May 2015 08:11:00 -0700 (PDT) In-Reply-To: <62FE5462-BE3F-4C9E-B03D-322CB0CFF753@gmail.com> 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:18238 Archived-At: ------=_Part_583_703389892.1432739460260 Content-Type: multipart/alternative; boundary="----=_Part_584_2123921756.1432739460260" ------=_Part_584_2123921756.1432739460260 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, May 27, 2015 at 4:51:58 AM UTC-4, Miro Knejp wrote: > > > On 27 May 2015, at 09:43 , Nicol Bolas >= =20 > wrote: > > >> [int,long,double] foo(); >> auto x =3D foo(); >> >> Ok, if tuple is out then what is decltype(x) in the above example doing= =20 >> things your way? >> > > There are two defensible answers to this: > > 1) A compilation error. You called a function that returns 3 things, but= =20 > you only captured one. That suggests you weren't paying attention. > > 2) `int`. The other two types are dropped on the floor. > > #2 is probably the way to go. Any sort of aggregate object type is not=20 > even up for discussion. > > Multiple return values means *multiple return values*, not "pack multiple= =20 > values into some kind of object and unpack them later". > =20 > >> Another kind of typelist which is standard layout compatible? Or are we= =20 >> no longer able to capture all of the return values into one object? >> > > If you want to capture them all in an object, you just ask for it: > > auto x =3D make_tuple(foo()); > > That is neither hard nor particularly verbose. You can even stick them in= =20 > an array, if all of the returned values are of the same type: > > auto x =3D make_array(foo()); > > Or in an arbitrary data structure: > > auto x =3D std::vector{foo()}; > > But most people using multiple return values don't capture them in a big= =20 > object, so we don't make the syntax optimal for that case. > > > I assume Matthew=E2=80=99s point comes from dealing with template code. > > template > ??? contrived_example(F f) { > return f(); > } > > The author would probably expect that ??? can be plain =E2=80=9Cauto=E2= =80=9D, implying=20 > =E2=80=9Cin some places auto can expand to multiple types=E2=80=9D. > Well, `auto` as a "return type" means something very different from `auto`= =20 as a variable declaration. So it's perfectly reasonable for `auto` or=20 `decltype(auto)` to deduce multiple return values. Just as it can deduce=20 `void` (ie: zero return values). =20 > Then there=E2=80=99s the point of what generic code would require to do t= o=20 > consistently capture the return value(s) of a Callable without knowing if= =20 > there are one or multiple return values. > > template > void contrived_example2(F f) { > ??? x =3D f(); > ... > } > That one's easy. Since you're in generic code and could be getting multiple= =20 values, the only way to manipulate them is with a tuple. So that's what you= =20 stick them in: auto x =3D make_tuple(f()); --=20 ---=20 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 e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_584_2123921756.1432739460260 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wednesday, May 27, 2015 at 4:51:58 AM UTC-4, Mi= ro Knejp wrote:

On 27 May 2015= , at 09:43 , Nicol Bolas <jmck...@gmail.com> wrote:


[int,long,double] foo();
aut= o x =3D foo();

<= /div>
Ok, if tuple is out then what is decltype(x) in the above example= doing things your way?

There are two defe= nsible answers to this:

1) A compilation error. You called a functio= n that returns 3 things, but you only captured one. That suggests you weren= 't paying attention.

2) `int`. The other two types are dropped on th= e floor.

#2 is probably the way to go. Any sort of aggregate object = type is not even up for discussion.

Multiple return values means multiple return values, not "pack multiple values int= o some kind of object and unpack them later".
 
Another kind of typelist which is standard layout = compatible? Or are we no longer able to capture all of the return values in= to one object?

If you want to capture them= all in an object, you just ask for it:

auto x =3D make_tuple(foo());

That i= s neither hard nor particularly verbose. You can even stick them in an arra= y, if all of the returned values are of the same type:

auto<= span> x =3D make_array(foo());<= /div>
Or in an arbitrary data structure:

auto = x =3D<= /span> std::v= ector<Type>{= foo()};
But most people using multiple return values don't capture them in a big = object, so we don't make the syntax optimal for that case.


I assume Matthew=E2=80=99s point comes from= dealing with template code.

template<class F>
??? contrived_example(F f) {
    return f();
}

The author would probably expect that ???= can be plain =E2=80=9Cauto=E2=80=9D, implying =E2=80=9Cin some places auto= can expand to multiple types=E2=80=9D.

We= ll, `auto` as a "return type" means something very different from `auto` as= a variable declaration. So it's perfectly reasonable for `auto` or `declty= pe(auto)` to deduce multiple return values. Just as it can deduce `void` (i= e: zero return values).
 
Then there=E2=80=99s the= point of what generic code would require to do to consistently capture the= return value(s) of a Callable without knowing if there are one or multiple= return values.

template<class F>
= void contrived_example2(F f) {
    ??? x =3D f();
=
    ...
}

That on= e's easy. Since you're in generic code and could be getting multiple values= , the only way to manipulate them is with a tuple. So that's what you stick= them in:

auto x =3D make_tuple(f());

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_584_2123921756.1432739460260-- ------=_Part_583_703389892.1432739460260-- .