220 23487 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: n4428 and Tuple-like access interface reflection Date: Tue, 05 Jan 2016 10:28:59 -0500 Lines: 93 Approved: news@gmane.org Message-ID: References: <56770133.7070701@wanadoo.fr> <5681D877.3010101@wanadoo.fr> <43daa6cd-e152-43c1-ab51-0661779d344b@isocpp.org> <568942A9.80700@wanadoo.fr> <568B0DA1.3080704@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1452007776 5787 80.91.229.3 (5 Jan 2016 15:29:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Jan 2016 15:29:36 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBTGCV62AKGQED2PGCXY@isocpp.org Tue Jan 05 16:29:27 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f69.google.com ([209.85.215.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aGTXx-0007Dh-ED for gclcip-std-proposals@m.gmane.org; Tue, 05 Jan 2016 16:29:17 +0100 Original-Received: by mail-lf0-f69.google.com with SMTP id b134sf81889866lfe.2 for ; Tue, 05 Jan 2016 07:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:date:lines:message-id:references:mime-version :content-type:user-agent: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=SXAW1pwxTwWuyiFnYG1vqOyi2AEFe8rAdpDWPzWcB0E=; b=S0g8JiqY/choe8i6T0aY29CqC7h0eW5kifSwSfr7ZFOI+QZK8EcWgcsKiFE/zf6cqP pRgR0r98Lvuf9w50eD/8UTHG/3JVueBneK9ZPvMkxFpmdQb1ZUGYQvtrdbMv5KCQ8x41 +Ep8uiTIv1Rnw8jL+TL0dgB7C3+EuB+lbb+QqE9d15JW9/YtwswSWsUKIyxwepu/afWx 52S+MibMO/cE2khaNgmc5bmxBHzf0GTZCtrgLVLrEtVfCYdh8IJYdB1YKYKIxyMuRFLG RP/WoMW0Sga8O4SsUts3V/sAMS7UBFhCTBmgKvY+b4wUTl0xKcnr76ZqGdrXHs2kr2Qj KqW X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:date:lines:message-id:references :mime-version:content-type:user-agent: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=SXAW1pwxTwWuyiFnYG1vqOyi2AEFe8rAdpDWPzWcB0E=; b=U8eySyc3I3YhawJ3XDwnTYm1v8PYc5d2PFYdvPExSJ+u/BGNQJ8SuH8ijRZMcYJerd B8jpCJYWWGej1v5wwv6JBWmBf/wbCeT7kQVOkFwl4I0MEekjHDSFp1Zs88bY+k5u8buj 7NY8JxNjHWFvIMoRFSsiA2X3i/AFmE+KX8mxFAC5wtXrZcYZ4cvRnyBHzJPvyg+91Pcd 2DUMa8B3XPCMuDSoi0+53k7zfY6e3ecTuzYXSE5A4xQrfQ5tCHCyBuLPAUf02KJXdj+k QgIo2FR42TxS317ksGyxe3O8b6nQEapQsyDIu0j4F8ZUvEDmr1DQgMme+u4+KEzPfkT9 X-Gm-Message-State: ALoCoQlOchQLBGwKHp4fH5+X/+MG94KTqKmJ77pY/RZcfnI3y1/IDUhLG0Pwaw1+DSTWn8w5KQfRkLZFzJigyLOhxlJyFBhm2Q== X-Received: by 10.112.155.136 with SMTP id vw8mr10837777lbb.13.1452007756951; Tue, 05 Jan 2016 07:29:16 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.210.196 with SMTP id j187ls625834lfg.52.gmail; Tue, 05 Jan 2016 07:29:15 -0800 (PST) X-Received: by 10.25.78.66 with SMTP id c63mr13663270lfb.18.1452007755490; Tue, 05 Jan 2016 07:29:15 -0800 (PST) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id ds8si54516602lbc.52.2016.01.05.07.29.15 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 05 Jan 2016 07:29:15 -0800 (PST) Received-SPF: pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aGTXm-00075K-JZ for std-proposals@isocpp.org; Tue, 05 Jan 2016 16:29:06 +0100 Original-Received: from tripoint.kitware.com ([66.194.253.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Jan 2016 16:29:06 +0100 Original-Received: from mwoehlke.floss by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Jan 2016 16:29:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 84 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tripoint.kitware.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: X-Original-Sender: mwoehlke.floss@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) smtp.mailfrom=gclcip-std-proposals@m.gmane.org; dmarc=fail (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:23487 Archived-At: On 2016-01-04 21:52, Nicol Bolas wrote: > On Monday, January 4, 2016 at 7:26:12 PM UTC-5, Vicente J. Botet Escriba > wrote: >> BTW, how can I check if a class is an aggregate? >> >> - array type >> - class type (typically, struct or union), that has I realize you are copying from the definition of aggregate, but I'll note that a union is probably not tuple-like :-). They can only have one active member, and the compiler can't generate code to know which member is active. Therefore, I don't see how you could implement the get-element (get or whatever) function for a union. >> - (1) no private or protected non-static data members >> - (2) no user-provided constructors (explicitly defaulted or deleted >> constructors are allowed) (since C++11) >> - (3) no base classes >> - (4) no virtual member functions >> >> I'm wondering if a type trait is_aggregate is not missing. > > Does it matter? > > The notion of "aggregate" really only matters for initialization: > aggregates undergo aggregate initialization. You're not actually trying to > initialize something; you're just creating tuple-style accessors for them. > > So why limit it specifically to non-virtual types? Agreed this may not be necessary. > And what's the point of the constructor limitation? None. Note however that C++14 already removes this restriction; I presume Vicente including it was accident/oversight. > The only limitation you absolutely need for > this automated system is having all NSDMs be public. Right. > Plus, C++17 is expanding the definition of aggregate to include types that > have aggregate base classes. Sure, and this makes sense for "tuple-like" also. > The way I see it, you should define the limitations that are most > reasonable for your feature, and give such types a name. Member-enumerable, > or public-accessible or something. Whether all such types are aggregates or > not is irrelevant. In fairness, I am probably partly at fault here. I have been using "aggregate" because that most closely matches the reasonable requirements. There may well be something of a disconnect between what should qualify for implicitly tuple-like and the standardese definition of "aggregate". (If there is a better term, please let me know; thanks!) So, the relevant question becomes, how do we determine if a complex type has no non-public NSDM's (without reflection)? On 2016-01-04 22:08, Ville Voutilainen wrote: > The question is why would you check for an aggregate? The goal is that get would be implicitly defined for any "aggregate". It should *not* be defined however for types that have non-public NSDM's. The question is how to achieve this. I should note that one answer is "compiler magic". If a standard trait is going to be a problem, that may be a strong argument to use compiler magic rather than a portable library solution. >> Maybe you are right, but having tuple_size::value/tuple_element::type >> defined and not having get seems to me risky and incoherent. *Are* they "defined"? The generic implementation of these should require that get<0>(tuple_like) is well formed. If no get<0> exists, the generic versions of tuple_size/tuple_element would not be well formed, with no need to explicitly specialize them. I could be wrong, though :-). -- Matthew -- --- 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 https://groups.google.com/a/isocpp.org/group/std-proposals/. .