220 28906 <94cbea29-edd8-9b46-a2f4-20aac92a6852@wanadoo.fr> article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Structured Bindings for all the Aggregates Date: Sun, 16 Oct 2016 23:18:04 +0200 Lines: 137 Approved: news@gmane.org Message-ID: <94cbea29-edd8-9b46-a2f4-20aac92a6852@wanadoo.fr> References: <4ecaea2b-35d0-4c1b-706c-9f1d668b112d@wanadoo.fr> <04845d0e-c10a-4b34-8c7f-ea6b2d32a33a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------07F32C7640A73F34D31A8565" X-Trace: blaine.gmane.org 1476652690 25487 195.159.176.226 (16 Oct 2016 21:18:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 16 Oct 2016 21:18:10 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBDW5R7AAKGQEWZLBU5Q@isocpp.org Sun Oct 16 23:18:06 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f71.google.com ([209.85.215.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bvson-0005uj-D5 for gclcip-std-proposals@m.gmane.org; Sun, 16 Oct 2016 23:18:05 +0200 Original-Received: by mail-lf0-f71.google.com with SMTP id n3sf87775971lfn.5 for ; Sun, 16 Oct 2016 14:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=eG6ckRk1tJlRXJuKqKKX5M44etdtCvYmfLrNxJWdZ5k=; b=vCEVBBX3qb3I4GSSb1jfL44706uo0RABApDoy7wPn2r4iSOeMGPhxArXsMQLtW4Evb vepPshz1va/HGJ+rLCPP4JrVorWdWrurCyjoqkNLnPPcYFo7qPQV0ZM7Lch3tT9MdVTS dtKUPJKZ1Ulu2OsN0kDGZFnDfS8mjRwh55HgOnWAeNvaEbxr7gWNjJ4v7Pol5d6C4cjj ltBGhwSTup07GTa2j+DnWemRsi0VDAdXy6r/TNeWsEZFbm5hZ6EzfJn83kmcNH6nrWAM v8cDE2za898tBsXav2IlxTh9zYx63+HDBq2HeNXq0+kUM9Fedf3VXuat5jFax7BLlJ71 7ruw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=eG6ckRk1tJlRXJuKqKKX5M44etdtCvYmfLrNxJWdZ5k=; b=GgsNty6ytfl+gD2Aw1Eq+XEGeQdlrw7+p2x8pdZc4t2NrAIj+AjLbKRnkeDDUHjHxp YLjlPJdc/s2LCuCpzicwvT4WjW33P4/5rdE9nz8Qg9W0RNRrwwUrqzxvnjVBFEh+ULjr m3PbunBwP8a/z0J6qL7UkIJtUQ5rDxroB3PhcQt1xsoLisLEgbJSoYW/SkByHviXchrN P6JFToU0LYtOe3mTjzId4uAwTg2dhz3lcUA24Uxr58A6szAl8eSlL4DneYecF7ZXCQ3N DWk2soKGevm1zzLNCCVhCg7ySqic6TXHgPBxLYayYOTZFS+9pgA0r9FANIq89231n1dg ZMyw== X-Gm-Message-State: AA6/9Rn3mlBYESbPr72zTViIlQlYZxKgOv4eJEUJOAd+3lEQNWPrWS5e1AszmajOnSBARA== X-Received: by 10.28.168.138 with SMTP id r132mr441080wme.0.1476652687811; Sun, 16 Oct 2016 14:18:07 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.21.160 with SMTP id 32ls1857548lfv.26.gmail; Sun, 16 Oct 2016 14:18:05 -0700 (PDT) X-Received: by 10.194.81.133 with SMTP id a5mr9426242wjy.86.1476652685516; Sun, 16 Oct 2016 14:18:05 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr. [80.12.242.129]) by mx.google.com with ESMTPS id yh8si9299568wjb.272.2016.10.16.14.18.05 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 16 Oct 2016 14:18:05 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.129 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.129; Original-Received: from pc29.home ([2.11.66.154]) by mwinf5d42 with ME id wMJ41t00D3KhaHe03MJ4LT; Sun, 16 Oct 2016 23:18:05 +0200 X-ME-Helo: pc29.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Sun, 16 Oct 2016 23:18:05 +0200 X-ME-IP: 2.11.66.154 In-Reply-To: X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.129 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr 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:28906 Archived-At: This is a multi-part message in MIME format. --------------07F32C7640A73F34D31A8565 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 16/10/2016 =C3=A0 21:44, Nicol Bolas a =C3=A9crit : > On Sunday, October 16, 2016 at 3:31:48 PM UTC-4, Barry Revzin wrote: > > Here's a better draft where we're clarifying the problem set and > dividing the world of types into three cases. The paper isn't > about aggregate initialization - it's about wanting the machinery > implicit to structured bindings available in a metaprogramming > context and wanting that machinery to by default apply to more > kinds of types. > > > First, your proposal needs to use the term "aggregate" correctly.=20 > Structured binding is not restricted to aggregates. The definition of=20 > "aggregate" requires that the type has no constructors. SB doesn't=20 > care if the type has constructors or not; it only cares about publicly=20 > accessible member variables and whether they're all declared in the=20 > same type. > > So there are types which are aggregates, and there are types which can=20 > use structured binding. At present, neither category is a subset of=20 > the other. > > Second, these really should be two different proposals. One being=20 > having a generic way to iterate over SB-capable types that don't=20 > explicitly implement the interface, with the other being an expansion=20 > of the requirements of SB-capable types. > > Lastly, I think having a formal name for SB-capable types (that is,=20 > types that would work without explicitly declaring the interface)=20 > would be a good idea. "Tuple-like" being the obvious one, but also=20 > "value sequence" or perhaps something else. Whatever it is, it's a=20 > concept that really needs a name. Product Type? https://github.com/viboes/std-make/blob/master/doc/proposal/reflection/p032= 7r1.md Vicente --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/94cbea29-edd8-9b46-a2f4-20aac92a6852%40wanadoo.f= r. --------------07F32C7640A73F34D31A8565 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 16/10/2016 =C3=A0 21:44, Nicol Bolas = a =C3=A9crit=C2=A0:
On Sunday, October 16, 2016 at 3:31:48 PM UTC-4, Barry Revzin wrote:
Here's a better draft where we're clarifying the problem set and dividing the world of types into three cases. The paper isn't about aggregate initialization - it's about wanting the machinery implicit to structured bindings available in a metaprogramming context and wanting that machinery to by default apply to more kinds of types.=C2=A0

First, your proposal needs to use the term "aggregate" correctly. Structured binding is not restricted to aggregates. The definition of "aggregate" requires that the type has no constructors. SB doesn't care if the type has constructors or not; it only cares about publicly accessible member variables and whether they're all declared in the same type.

So there are types which are aggregates, and there are types which can use structured binding. At present, neither category is a subset of the other.

Second, these really should be two different proposals. One being having a generic way to iterate over SB-capable types that don't explicitly implement the interface, with the other being an expansion of the requirements of SB-capable types.

Lastly, I think having a formal name for SB-capable types (that is, types that would work without explicitly declaring the interface) would be a good idea. "Tuple-like" being the obvious one, but also "value sequence" or perhaps something else. Whatever it is, it's a concept that really needs a name.
Product Type?

https://github.com/viboe= s/std-make/blob/master/doc/proposal/reflection/p0327r1.md

Vicente

--
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/94cbea29-edd8-9b46-a2f4-20aac92a6852= %40wanadoo.fr.
--------------07F32C7640A73F34D31A8565-- .