220 18203 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: Tue, 26 May 2015 11:47:42 -0700 (PDT) Lines: 106 Approved: news@gmane.org Message-ID: References: <69a59613-6504-466a-9878-786653d6087f@isocpp.org> <4498da2a-af3a-457d-9bf7-e8bb3721d6b9@isocpp.org> <5947190.lVlccHFjdM@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4618_33968875.1432666062666" X-Trace: ger.gmane.org 1432666071 21539 80.91.229.3 (26 May 2015 18:47:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 May 2015 18:47:51 +0000 (UTC) Cc: jmckesson@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBT77SKVQKGQEISZB7WY@isocpp.org Tue May 26 20:47:46 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YxJtB-0008Mg-3d for gclcip-std-proposals@m.gmane.org; Tue, 26 May 2015 20:47:45 +0200 Original-Received: by iebll7 with SMTP id ll7sf228284587ieb.2 for ; Tue, 26 May 2015 11:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=DYw8xKwBU2b2lRHEKtmhwAOkNsW/3kyfCN2IZ7Sv+bU=; b=Y/mC8Uax7gHWbk4Trdkh3UrjuDISg4734hvA9BeU70kcG8G3wS+Ok/IJwzCHY6bUj4 MWwHvnvotnbJglbiz4nkD9hhYdgEGgi7Zt955ccd6jkGbQG1UsPqr2Yzjcjp+b51y6S6 9jqMGMHeOmHc40M/D0ZUdrSaPDKjcraBMfMAdnFt7gurzGKGUDbcXSz6/SWz1GM0xSW9 DG7ftNzlrv1XwnDtgY0m5SsBJ+OycedHvkbZ/14MPsAINEYw+RCM7n4myLg6CyID6Nkr YhvHyokeexC23noh0+dbQkDOcgbtNdWaO0NKSSE1dcYbOUcw01tCAaJ4n7iNRfT8AU6z tMwg== 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:cc: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=DYw8xKwBU2b2lRHEKtmhwAOkNsW/3kyfCN2IZ7Sv+bU=; b=mqvxvlOu+3+BF+fB4f9AC1o+XN/+FpmHz7q+Lp01NlqVFvYZ+CpqFaBs/wRxu7TuHJ K47+MeOUWObec4m4FZCef2IcVSezM1E0wrqq8dJUTNyIpZtm1Ef8udRkiOqMsGPGzKsq OQiUOiIpiOGe8Ak+OGYHRPVtD4DBWGus4QdWiqxc+vmaJhgtw91Y4bQwqoTPvdoZ9pdo e2G8BsYYnfBRYwpdQgxu3OKumcXHFcX3ZJDuC7YUwQWYSAXSX6BNXxJ6Rxs3Z9OMKLih fNjduxr0ZTIzAxK6aDpew9LMXqJ+xoTDZRBjOamBAGwyDG0xtIlWsl5FKFkZdzowhU4v Jb2g== X-Gm-Message-State: ALoCoQnsnsTit53IhTiFvd59ZBSC2nhhxUVJf0bTtMHypj+oUTyVtWPoW22VZm4Imq7v+B5yLdzI X-Received: by 10.42.151.195 with SMTP id f3mr36732144icw.8.1432666064146; Tue, 26 May 2015 11:47:44 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.43.181 with SMTP id e50ls2552343qga.6.gmail; Tue, 26 May 2015 11:47:43 -0700 (PDT) X-Received: by 10.140.97.7 with SMTP id l7mr352000qge.0.1432666063428; Tue, 26 May 2015 11:47:43 -0700 (PDT) In-Reply-To: <5947190.lVlccHFjdM@tjmaciei-mobl4> 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:18203 Archived-At: ------=_Part_4618_33968875.1432666062666 Content-Type: multipart/alternative; boundary="----=_Part_4619_1831715670.1432666062666" ------=_Part_4619_1831715670.1432666062666 Content-Type: text/plain; charset=UTF-8 On Tuesday, May 26, 2015 at 2:34:23 PM UTC-4, Thiago Macieira wrote: > > > I think the matching return and capture is a very important point, since a > lambda and this return are both basically anonymous structs. > > return [x = 5, y = 10] {} > > If it were possible to extract the captured variables, we'd have half the > job > done. > I'm not sure returning an anonymous type is actually desirable at all for this feature. Lambda types are anonymous because they have a function call operator that can do whatever and the type system cannot compare the behavior of 2 lambdas operator() to prove they behave identically. An [int,float,double] on the other hand does not need to be anonymous because there is no ambiguity. Its just a type list like container holding these 3 objects. Anonymous types come with a lot of baggage - We have to use auto as the return type of the function, which for a large function can reduce readability. - Any function returning multiple values will need to be written in the header file, no out of line functions allowed. (this is really bad imo) - The function body can only have 1 return statement, as each invocation returns a different anonymous type. Is there any feature of an anonymous type that is actually beneficial? A proposal that just defines a syntax sugar for defining a tuple type and a syntax sugar for generating optimal code to extract values from tuple would be simple to understand and give us the multiple return value idiom as first class citizens in C++. -- --- 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_4619_1831715670.1432666062666 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tuesday, May 26, 2015 at 2:34:23 PM UTC-4, Thia= go Macieira wrote:

I think = the matching return and capture is a very important point, since a=20
lambda and this return are both basically anonymous structs.

        return [x =3D 5, y =3D = 10] {}

If it were possible to extract the captured variables, we'd have half t= he job=20
done.

I'm not sure returning an anonymous type is actua= lly desirable at all for this feature. Lambda types are anonymous because t= hey have a function call operator that can do whatever and the type system = cannot compare the behavior of 2 lambdas operator() to prove they behave id= entically. An [int,float,double] on the other hand does not need to be anon= ymous because there is no ambiguity. Its just a type list like container ho= lding these 3 objects.

Anonymous types come with a lot of baggage- We have to use auto as the return type of the function, which for a larg= e function can reduce readability.
- Any function returning multiple val= ues will need to be written in the header file, no out of line functions al= lowed. (this is really bad imo)
- The function body can only have 1 retu= rn statement, as each invocation returns a different anonymous type.
Is there any feature of an anonymous type that is actually beneficial?
=
A proposal that just defines a syntax sugar for defining a tuple type a= nd a syntax sugar for generating optimal code to extract values from tuple = would be simple to understand and give us the multiple return value idiom a= s first class citizens in C++.

--

---
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_4619_1831715670.1432666062666-- ------=_Part_4618_33968875.1432666062666-- .