220 28805 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Structured Bindings for all the Aggregates Date: Thu, 13 Oct 2016 09:28:28 -0700 (PDT) Lines: 115 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_457_702746525.1476376108187" X-Trace: blaine.gmane.org 1476376141 20236 195.159.176.226 (13 Oct 2016 16:29:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Oct 2016 16:29:01 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBLPM727QKGQE5OFVUOQ@isocpp.org Thu Oct 13 18:28:57 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f197.google.com ([209.85.161.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buirx-0002BK-BT for gclcip-std-proposals@m.gmane.org; Thu, 13 Oct 2016 18:28:33 +0200 Original-Received: by mail-yw0-f197.google.com with SMTP id 202sf145623515ywx.6 for ; Thu, 13 Oct 2016 09:28:35 -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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=TDCSovyM4IOxa4vBwD23NO+4lRhM6eTDD/PL0iiL0DU=; b=Zizkm+5DiALqdnYoA051Pko6Dxsp+0L/AxrzhbcFcQPr+9nisfGt5ieJqR95ksZNnR HTjc4cX1nH9nHCChbCOfcb2htXyasH25D0pqTaeKFsJvI1xbsHuEz3aYmMX1FPuNxPQ4 enG2Mgo8HqC73vRGMlplc9gpug7OpR1ds+JFNZfxQGnA2KICqPwE+0qJ0sh7R2OI1LdB RBSRZ8v8IjuM8Z7TcouvnFcvj8twTEsjr8qnFtCQw3/IqXmmCuTLnrTSkfMNBTfdm0ln veoWVdMLJyMbOkTSDEo4kFaaJsNbPNJ3XP32AVVhlU90j/gfUkVuGlTiuRy6WTJISDNv z2Eg== 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 :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=TDCSovyM4IOxa4vBwD23NO+4lRhM6eTDD/PL0iiL0DU=; b=Mbx3uXHmHy4DkMsJHqutqp1HJQ7nBgPB+D5CJnAN5OnMvbisRZ3yoTgKcGpvJhSzei tbk+dbTebV5xJqdjk9kfX+F4E+ubBmqxLPycK4gS9KXJ5QeBqpX4TdehLOEJwN3GD+lK fVY6vb8W0tVIW0Vl4PX+aQBzNfr2bpp9v9KR3v/LVbcd3TNnUoxMgq41xtM8O8ZuPHjg wGctUiA7MaVvzWAX6QJy6plc26zldTj1iIS6EJ9A2eHVwPaFGH8JskX48KNiglhJn32/ AB1K1Kp2e4GCpXaoqZEsfh8VosQcOTlbUs5OH6j9AdDzSNloOnoAisKdf4mRd45Z2vdX 46Bg== 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: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=TDCSovyM4IOxa4vBwD23NO+4lRhM6eTDD/PL0iiL0DU=; b=gMERCL/fpff62Gz6vPsToggOEsmezbZzxaO/7dJq6MVIudvXpGErwFdzjY+LEQBEX6 zXex4O5SIqi15eYY0dr5TweVmaCFzsjCs9twjo4MlI2psvoVV4rFJ4YRJDk9pAZsJRb1 ogBFKUofRn0J0RRhJiTYb29mE35zxFSeSXQL5HL+am+Geu5FgjLe4ZZfls4l3plX5k6G gEuRqRm7EbTyJRtSOgvb9D0WmzJj+V9uG2xR8SS6M+o9xu4usViiaok8O/bmsXQ/qvdG Bo001joNjotkjQr7asEi6Bo6jI0/sz7lsehG65qz8bKTSpBvaW/X1pdZS6FH+E/917nM lfNQ== X-Gm-Message-State: AA6/9RmsEHIVTLM4uwpd3J+WU50mwWLyv0dTq+sZwooE3CxHFdbFbWC8YPu8ah246XsqqA== X-Received: by 10.129.82.22 with SMTP id g22mr1665335ywb.72.1476376115295; Thu, 13 Oct 2016 09:28:35 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.6.200 with SMTP id f69ls2431167ioi.12.gmail; Thu, 13 Oct 2016 09:28:29 -0700 (PDT) X-Received: by 10.36.124.195 with SMTP id a186mr688825itd.7.1476376109132; Thu, 13 Oct 2016 09:28:29 -0700 (PDT) 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:28805 Archived-At: ------=_Part_457_702746525.1476376108187 Content-Type: multipart/alternative; boundary="----=_Part_458_1247808455.1476376108187" ------=_Part_458_1247808455.1476376108187 Content-Type: text/plain; charset=UTF-8 On Thursday, October 13, 2016 at 11:14:11 AM UTC-4, Barry Revzin wrote: > > SB does not flatten anything. It simply looks at public members of a type. >> [...] >> And yet, C2 and C will not be different in terms of aggregate >> initialization. Your whole premise is that SB should work like the reverse >> of AI. >> > > Maybe I misworded the original proposal, but our premise isn't that SB and > AI should be inverses. The premise is that an aggregate is just a > collection of values - whether those values are all in one type directly or > not. > This premise is not supported by the C++ standard's definition for "aggregate". An aggregate is a collection of *objects*, not of values. And the subobjects in an aggregate may themselves have subobjects. "whether those values are all in one type directly or not" is not something the C++ standard dismisses. The arrangement of objects in an aggregate *matters*, not just in their order, but in which subobjects they are members of. Aggregates are not flat in C++, and nothing in the standard has ever made them so. SB should be able to unpack an aggregate into all of its underlying values > - which would be all the public members, not the base class subobjects. So > yes, I agree that C and C2 would both be aggregate-initializable with two > ints, but C really has two int members so it should unpack into two ints - > whereas C2 has a B and an int and should unpack in those. > And you're explaining exactly why SB doesn't do this. You believe that a base class member should be treated as if it were a direct member of the derived class. I believe otherwise. The standard's aggregate rules don't agree with you either. As such, one user will expect SB to unpack the "underlying values", while another user will expect SB to unpack the *subobjects* in the type. By forbidding this case entirely, the standard ensures that there is no confusion. -- 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/cda97908-314b-4ff6-aba7-c67f92b1bac7%40isocpp.org. ------=_Part_458_1247808455.1476376108187 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thursday, October 13, 2016 at 11:14:11 AM UTC-4, Barry = Revzin wrote:
=
SB does not f= latten anything. It simply looks at public members of a type. [...]
And yet, C2 and C will not be different in terms of aggregate initializa= tion. Your whole premise is that SB should work like the reverse of AI.

Maybe I misworded the origina= l proposal, but our premise isn't that SB and AI should be inverses. Th= e premise is that an aggregate is just a collection of values - whether tho= se values are all in one type directly or not.

This premise is not supported by the C++ standard's definition for= "aggregate". An aggregate is a collection of objects, not= of values. And the subobjects in an aggregate may themselves have subobjec= ts. "whether those values are all in one type directly or not" is= not something the C++ standard dismisses. The arrangement of objects in an= aggregate matters, not just in their order, but in which subobjects= they are members of.

Aggregates are not flat in C++, and nothing in= the standard has ever made them so.

SB should be able to unpack an ag= gregate into all of its underlying values - which would be all the public m= embers, not the base class subobjects. So yes, I agree that C and C2 would = both be aggregate-initializable with two ints, but C really has two int mem= bers so it should unpack into two ints - whereas C2 has a B and an int and = should unpack in those.

And you're= explaining exactly why SB doesn't do this.

You believe that a b= ase class member should be treated as if it were a direct member of the der= ived class. I believe otherwise. The standard's aggregate rules don'= ;t agree with you either. As such, one user will expect SB to unpack the &q= uot;underlying values", while another user will expect SB to unpack th= e subobjects in the type.

By forbidding this case entirely, t= he standard ensures that there is no confusion.

--
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/cda97908-314b-4ff6-aba7-c67f92b1bac7= %40isocpp.org.
------=_Part_458_1247808455.1476376108187-- ------=_Part_457_702746525.1476376108187-- .