220 18253 <1335ae00-da12-4aca-864d-e4380018c692@isocpp.org> article Path: news.gmane.org!not-for-mail From: Matthew Fioravante 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 09:30:13 -0700 (PDT) Lines: 422 Approved: news@gmane.org Message-ID: <1335ae00-da12-4aca-864d-e4380018c692@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> <22a4d6a5-f6f1-4ed1-9ec9-743c32173f81@isocpp.org> <67f765e2-8b7e-4a78-a548-643b691d0a72@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2068_270510071.1432744213275" X-Trace: ger.gmane.org 1432744227 28507 80.91.229.3 (27 May 2015 16:30:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 May 2015 16:30:27 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBFXCS6VQKGQEJPVJ4XY@isocpp.org Wed May 27 18:30:21 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YxeDf-0006rX-RA for gclcip-std-proposals@m.gmane.org; Wed, 27 May 2015 18:30:16 +0200 Original-Received: by oihd6 with SMTP id d6sf22710802oih.1 for ; Wed, 27 May 2015 09:30:15 -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=4l9UPdAYfF0wKZQdIcusPA2Ty2YRxgk/VGKztg9dqrc=; b=RMzxIujOU/4a1ljpAr44gKZkOego/pB8qji5Sn7w1pa0q8fVjxYdtBMbaKhWQBK3D7 8vxjaU5Y/UWviU/B4TN+lr11S3H2QI5SE5n90+Soa8wWLwohoOGA/gjOkkICG39Ddt9p XrWLOW6IrGWkZe8uaxKKPNxUk0o8QZITsFjRHZLftFIsE7YjKwl2dzMe1V923vQbIfGn 8z5h5GGRLuwyPTMUu0L8VrGKULi+mareTOdzWNqBZZBAFmNdNQL+0TerrGINSKg20mLD a4i6NVbSvBY+9XqzJSdKbahYURzcKsoAj2cSXfxsi0p0nC/sNCAEzaS7ZF1Ru65oUaej g40w== 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=4l9UPdAYfF0wKZQdIcusPA2Ty2YRxgk/VGKztg9dqrc=; b=jj/AI0ez9y2RbS8MQSzrbdDMik6flJTtqBPOF58aKewlrTXgQJgCDHA5RXjzJGZwHn ODIK+/RS5eqkuOhukxw3ttwrD2VIYABBEzZxelND4kEi/9oW5+t15EE0auyUS5+IXnHp jBbH/fTHPyDoWnI9eYNjQJa4i1hphvHFZqoOvJRh20fIKcvwVRrX40wroOqFc54cpB7T 6lvm2OyBX1pubYFZCrviRjmwktiLIUVOyAG/xQO9GRo+TBpiZsE4ZFz+dZg2ktSzulP9 WZMkU+8Gz8J52uLPIBzmDOXGsZCvDLRhIDLTa+Wsl1WwVa3k5UHB0Ci8ECpGtv00YXBD YwpQ== X-Gm-Message-State: ALoCoQlYdIIUQwsxvbRdHPNlnrxz1Lekzd+SQJkzhC6ejD5bJhT+98wpg7M48LTweRH0wVAEWJx8 X-Received: by 10.182.236.197 with SMTP id uw5mr43198210obc.32.1432744215023; Wed, 27 May 2015 09:30:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.97.136 with SMTP id m8ls271051qge.94.gmail; Wed, 27 May 2015 09:30:14 -0700 (PDT) X-Received: by 10.140.37.129 with SMTP id r1mr420108qgr.18.1432744214068; Wed, 27 May 2015 09:30:14 -0700 (PDT) In-Reply-To: <67f765e2-8b7e-4a78-a548-643b691d0a72@isocpp.org> X-Original-Sender: fmatthew5876@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:18253 Archived-At: ------=_Part_2068_270510071.1432744213275 Content-Type: multipart/alternative; boundary="----=_Part_2069_239882598.1432744213275" ------=_Part_2069_239882598.1432744213275 Content-Type: text/plain; charset=UTF-8 On Wednesday, May 27, 2015 at 11:59:36 AM UTC-4, Nicol Bolas wrote: > > On Wednesday, May 27, 2015 at 11:11:34 AM UTC-4, Matthew Fioravante wrote: >> >> On Wednesday, May 27, 2015 at 3:43:10 AM UTC-4, Nicol Bolas wrote: >> >> Except that they have to pay the cost for it. Consider something simple >> like this: >> >> auto single_value() >> { >> std::string a = ...; >> return a; >> } >> >> auto multi_value() >> { >> std::string a = ...; >> std::vector b = ...; >> return [a; b]; >> } >> >> `single_value` is subject to copy elision, so you should feel no problem >> with using it. Even with a small-string-optimized std::string class, you >> will get the maximum possible performance if you're using the result to >> initialize an object. >> >> With language-level multiple return values, `multi_value` would be able >> to operate under the same principle. `a` and `b` would be considered return >> values, and they would each be separately subject to elision. >> >> With your way, that's just not possible. If that syntax creates a >> `tuple`, then it must copy or move initialize the elements of that `tuple`. >> So even though the `tuple` itself is subject to elision, the creation of it >> is not. >> >> >> So whats stopping someone from writing a proposal to allow copy/move >> elision in your multi_value() example? >> > > The fact that C++ can't do that. Remember: your [values...] syntax equates > to the construction of a `std::tuple` from the given values. Well, the > memory for those values has already been allocated, and if those are > variables, then the memory there must have been allocated elsewhere. And > because `std::tuple` is not *special*, because it must follow the regular > rules of C++, there's no way for a compiler to know (without very non-local > optimizations) exactly what that constructor is doing. > If tuple (or whatever type we use, lets call it tuple) constructor is inline and just trivially constructs the members, as it should be then the compiler can do whatever it wants. I don't see why the constructor cannot construct the string directly in the memory to be used by the returned tuple. > Furthermore, even if a compiler did know... what of it? Are you suggesting > that the compiler can, or should be allowed to, initialize the memory space > in a `tuple` before the object is even constructed, then ignore the tuple's > constructor? > Sure, if the constructor is inline and we can prove "as-if" compatible behavior why not? > > I'd hate to have to implement that in a compiler. > > >> Just because it can't happen now doesn't mean we can't change the >> standard. Multi return values would be a primary use case for such a >> proposal. >> > > If the standard were changed, it couldn't be changed in anything remotely > like a generic way. It would have to be based on a basic assumption that > `[values..,]` syntax doesn't generate a `std::tuple`, but some other > compiler-generated object type. And this type would be treated specially by > the language, being allowed to skip constructors. > > Otherwise, you'd have to define some general way for the compiler to know > whether a constructor parameter would be stored in a tuple exactly as-is or > not. > > Also what if I want to save the sequence so that I can forward it multiple >> times? >> Using your approach, I might suggest allowing auto... to capture all of >> the return values so that they can be forwarded along. This could work just >> like a variadic template parameter pack. >> >> void foo(int, float); >> [int, float] bar(); >> >> auto... x = bar(); >> foo(x...); >> foo(x...); >> >> > Now that... that sounds like an idea. I've always wanted a way to build a > template parameter pack. > > I think that it would be possible to consider the "sequence of values" > concept to be a template parameter pack. Thus, functions can create and > return parameter packs, which can be unpacked by the user, or not unpacked > by the user, as the case may be. > > So if we consider [values...] to create a parameter pack, then the > assignment syntax would look something like this: > > [] = pack...; > > The specific syntax can be worked out (I don't think any of these things > can move forward with `[]` notation, due to various parsing issues). But > that would be the general idea. > > It wouldn't be as good as the Lua syntax. But I think this way regularizes > parameter packs as "sequences of values" in a useful way. > > >> But we still have the generic code problems that Miro brought up. >> >> >> >> Multiple return values means *multiple return values*, not "pack >> multiple values into 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 into one object? >> >> >> If you want to capture them all in an object, you just ask for it: >> >> auto x = make_tuple(foo()); >> >> That is neither hard nor particularly verbose. You can even stick them in >> an array, if all of the returned values are of the same type: >> >> auto x = make_array(foo()); >> >> >> These require copy/move. In your example, unpacking is free (no-op) and >> packing requires a copy/move. In my example unpacking is free (using >> references) and packing is also free, assuming you want to continue using >> the pack type returned by the function. >> > > But as previously stated, packing *is not free* in your system. Packing > requires the function doing the packing (the one returning the tuple) to > either put the values in the tuple itself or copy/move the values into the > tuple. Until you actually propose a way to fix that problem (rather than > simply declaring that it can be fixed... somehow), your proposal must be > evaluated as though such a solution doesn't exist. > Your performance concerns are valid and I agree that any proposal would need to address them directly and prove that they can either be mitigated or that they are worth the cost. > > >> >> Or in an arbitrary data structure: >> >> auto x = std::vector{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. >> >> >> Its not uncommon. Every class that has multiple "values" (e.g >> unordered_map) will be returning them in a pack using its default >> iterators so that one can write a simple range for loop. >> > > And how often do people iterate through maps? The main purpose of a map is > to efficiently look up items by a key. > > So I'd say it's still relatively uncommon. It's certainly not common > enough to make a special syntax for tuples. > > ... *that being said*, I wouldn't mind `...` being able to unpack a tuple > or other tuple-like construct in addition to a proper parameter pack (note: > this is barring any syntactic issues, like breaking existing code). > Granted, it wouldn't resolve that problem, but it would normalize tuple as > the way to store a parameter pack as a free-standing object, rather than a > compiler construct. > -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_2069_239882598.1432744213275 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wednesday, May 27, 2015 at 11:59:36 AM UTC-4, N= icol Bolas wrote:
On Wednesday, May 27, 2015 at 11:11:34 AM UTC-4, Matthew Fioravante wro= te:
On Wednesday, M= ay 27, 2015 at 3:43:10 AM UTC-4, Nicol Bolas wrote:
Except that they have to pay the cost for it. Consider some= thing simple like this:

auto single_value()<= span style=3D"color:#000">
{
  std::<= /span>string a= =3D ...;
&= nbsp; return a;
}<= br>
auto multi_value()
{
  std::string a =3D ...;
  std::vector b =3D ...;
&nbs= p; return [a; b];
= }

`single_value` is subject to copy elision, so you should feel no problem with using=20 it. Even with a small-string-optimized std::string class, you will get=20 the maximum possible performance if you're using the result to=20 initialize an object.

With language-level multiple return values, `multi_value` would be able to operate under the same principle. `a`=20 and `b` would be considered return values, and they would each be=20 separately subject to elision.

With your way, that's just not=20 possible. If that syntax creates a `tuple`, then it must copy or move=20 initialize the elements of that `tuple`. So even though the `tuple`=20 itself is subject to elision, the creation of it is not.

So whats stopping someone from writing a proposal to all= ow copy/move elision in your multi_value() example?

The fact that C++ can't do that. Remember: your [values...] synta= x equates to the construction of a `std::tuple` from the given values. Well= , the memory for those values has already been allocated, and if those are = variables, then the memory there must have been allocated elsewhere. And be= cause `std::tuple` is not special, because it must follow the regula= r rules of C++, there's no way for a compiler to know (without very non-loc= al optimizations) exactly what that constructor is doing.

If tuple (or whatever type we use, lets call it tuple) = constructor is inline and just trivially constructs the members, as it shou= ld be then the compiler can do whatever it wants. I don't see why the const= ructor cannot construct the string directly in the memory to be used by the= returned tuple.


Furthermore, even if a compiler did know... what= of it? Are you suggesting that the compiler can, or should be allowed to, = initialize the memory space in a `tuple` before the object is even construc= ted, then ignore the tuple's constructor?
=
Sure, if the constructor is inline and we can prove "as-if" compatible = behavior why not?
 

I'd hate to have to implement that in a co= mpiler.
 
Just because it can't happen now doesn't mean we can't change the= standard. Multi return values would be a primary use case for such a propo= sal.

If the standard were changed, it = couldn't be changed in anything remotely like a generic way. It would have = to be based on a basic assumption that `[values..,]` syntax doesn't generat= e a `std::tuple`, but some other compiler-generated object type. And this t= ype would be treated specially by the language, being allowed to skip const= ructors.

Otherwise, you'd have to define some gener= al way for the compiler to know whether a constructor parameter would be st= ored in a tuple exactly as-is or not.

Also what if I want to save the seque= nce so that I can forward it multiple times?
Using your approach, I migh= t suggest allowing auto... to capture all of the return values so that they= can be forwarded along. This could work just like a variadic template para= meter pack.

void foo(int, float= );
[= int, float] bar();

auto... x =3D bar();
foo(x...);
foo(x...);


Now that... that sounds like an idea. I've always w= anted a way to build a template parameter pack.

I think that it woul= d be possible to consider the "sequence of values" concept to be a template= parameter pack. Thus, functions can create and return parameter packs, whi= ch can be unpacked by the user, or not unpacked by the user, as the case ma= y be.

So if we consider [values...] to create a parameter pack, then= the assignment syntax would look something like this:

[] =3D pack..= ..;

The specific syntax can be worked out (I don't think any of these= things can move forward with `[]` notation, due to various parsing issues)= .. But that would be the general idea.

It wouldn't be as good as the = Lua syntax. But I think this way regularizes parameter packs as "sequences = of values" in a useful way.
 
But we still have the generic code problems t= hat Miro brought up.
 

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

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

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

That is neither hard nor particularly verbose. You can even stick them in an array, if all of the returned values are of the same type:

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


These require copy/move. In your example, unpacking is free (n= o-op) and packing requires a copy/move. In my example unpacking is free (us= ing references) and packing is also free, assuming you want to continue usi= ng the pack type returned by the function.

But as previously stated, packing is not free in your system. P= acking requires the function doing the packing (the one returning the tuple= ) to either put the values in the tuple itself or copy/move the values into= the tuple. Until you actually propose a way to fix that problem (rather th= an simply declaring that it can be fixed... somehow), your proposal must be= evaluated as though such a solution doesn't exist.

Your performance concerns are valid and I agree that any prop= osal would need to address them directly and prove that they can either be = mitigated or that they are worth the cost.
 

 
Or in an arbitrary data structure:
<= span style=3D"color:#008">auto x <= span style=3D"color:#660">=3D std<= span style=3D"color:#660">::vector= <Type>{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.
<= /blockquote>

Its not uncommon. Every class that has multiple "value= s" (e.g unordered_map)  will be returning them in a pack using its def= ault iterators so that one can write a simple range for loop.

And how often do people iterate through maps? The m= ain purpose of a map is to efficiently look up items by a key.

So I'= d say it's still relatively uncommon. It's certainly not common enough to m= ake a special syntax for tuples.

... that being said, = I wouldn't mind `...` being able to unpack a tuple or other tuple-like cons= truct in addition to a proper parameter pack (note: this is barring any syn= tactic issues, like breaking existing code). Granted, it wouldn't resolve t= hat problem, but it would normalize tuple as the way to store a parameter p= ack as a free-standing object, rather than a compiler construct.
<= /div>

--

---
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_2069_239882598.1432744213275-- ------=_Part_2068_270510071.1432744213275-- .