220 36757 article Path: news.gmane.org!.POSTED!not-for-mail From: Bastien penavayre Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: meta members: a 0+ cost properties & dot operator Date: Sun, 28 Jan 2018 19:15:45 +0100 Lines: 231 Approved: news@gmane.org Message-ID: References: <11f9c7ff-aa76-46a5-94b2-0692171ab0ff@isocpp.org> <437c4139-06b9-4751-aa2f-dea9563266dd@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403045d5aec4921080563da1ef6" X-Trace: blaine.gmane.org 1517163235 1423 195.159.176.226 (28 Jan 2018 18:13:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Jan 2018 18:13:55 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCG3XHNI6IDRBUVGXDJQKGQEDNHT5KA@isocpp.org Sun Jan 28 19:13:51 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr0-f199.google.com ([209.85.128.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1efrSY-0007zx-VA for gclcip-std-proposals@m.gmane.org; Sun, 28 Jan 2018 19:13:43 +0100 Original-Received: by mail-wr0-f199.google.com with SMTP id q8sf3823821wrd.17 for ; Sun, 28 Jan 2018 10:15:47 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1517163347; cv=pass; d=google.com; s=arc-20160816; b=h/Mzs4tHqTR7SCn4JsOu+qoik9IoteeS5K8FiDUjULVrfu6+y/Tfx4ipVGnjkRClmP Rry+gS9MZA2hJ6gbDmGFyiPn84VWTtyQ4/dEs7hDMeOPZdblZFOe+Hi2vW3Iqe0NQjR3 V/2KNrxiES7HaqT5SG8wydWOCWMjf/1aO0VMe8pgRf10syQ7eFKWsVztP1F9Ll5rJKm4 xpCQRrRe23foPa4hLbKbswb5N00XLf5p9EMGl5CSf9q/LamJjkswb0A1wRNnoaZNfbJm fjUgr1XKBLpIDZUDKZQv7ccjoUcr3wHk+RK75g9ftmFKKNTqoAmuUPFSlVjrrpuYNvuA q0cw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=R261IcZ+nL5Y72yiJLd3X0xVnPLxUA8Ybj7VqwaTE7I=; b=EDj9Jix4/OE2lWHSnp6uma2vHC2d5oUwrdubmDL0tXEtujAz3WrdI2JUyQtBMvIQLl e8FEGtLsYy3s5EKuDwxzn91Qmi/V4ZXXhjMnpM/5iXvftvuppryn4V9RXXoi1v8XkQza 5aBfzqS5bprzEm+nB8NRgS/cY9e8aZgnZI5ia3mU2i1L+ScuvAXMWZOU3i0WFGQSs8a8 d6xNjH/FVfqMJ1M5eAfpCj6pSDxgKyZN9+ArtAFZ2v5wvnO2kWCb6118qBs3kl21qzZf bB5SOYXaApo5vCVIfcM94ghkYGp1sSIPv+F+5htCtgsB33KZAL69SyQt20vRtn9b92u5 r0XA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dGpZIRxP; spf=pass (google.com: domain of bastienpenava@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=bastienpenava@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=R261IcZ+nL5Y72yiJLd3X0xVnPLxUA8Ybj7VqwaTE7I=; b=TRqPGMqQ1VLi3x1JiUj9BParzJCkCfhmyMWlieNUe3vBmAeU9l6nhD0KuRa/WfJQp1 HHnY6lKbr/mf9vgY88T6+WjsVGedFZiFVVYqQAS1uVisZKxK4QOsIxj5YZ7XkFyh/OFv VLX5JZc3Ew1WZXd5jXA/bvVs388tT/GlXcaQgDZOiJWS2rOwiOTfUY4V/MhWAxDKJ3TA 2640Y0j1IVKqlhf4onKMK7Q4CgtwOL/HJEjWMjZshYsybHj1jqHyRaMgv/ECDf3gp1aV VXkVXGzyQl9LxR4y7OK26dsGNECldGMHfPzISv3Mw4E1auS8DhjMMhsSmCc400BKPndD n0wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject: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=R261IcZ+nL5Y72yiJLd3X0xVnPLxUA8Ybj7VqwaTE7I=; b=X3Am26WeEiRzgvqDDNkxh7P3Sc1TqfFF1U6HFWhFIWYMjysTRliTR22IOAqqLuGwgc +ie4VUBbIkYhG/KXLI8t4R3Chkq+Q7SNSThrQ6e/Ll1cHJWEK82Pc5UxUbk4Ito3WTOb 69x7KKJa7929bFjIBtRiLM50KQ6A25eBCO+M33nS5hOMfi65c9+p7rIE5BPuNGYKRkli FDxH4woqncyKIHDqAnZ6DalrS1ikIVofC421bClClLdaGN3RDRJUt5Pq6qrEkApiI1ZE fESbdIt8RBtKlhsAkksgPmKMZYPQ6vABfRrr60fDqoFlDi8OrGIrZOQpePL5B2GjQzMK E6qw== X-Gm-Message-State: AKwxytfmCM75OL+yqINVEXgBfPWiCqL7ib3QO57S4mDYWGZVTSnarWnh 19fwsW9L173jJcfLqrsNZsu11A== X-Google-Smtp-Source: AH8x227I6jW4R3Z5OOONjLZxhdAGRuH+79ICPF5O51AE6FEdyqr7wljj8Yxh/cWAGvC6XeqzIynKPg== X-Received: by 10.223.179.28 with SMTP id j28mr2240244wrd.30.1517163347750; Sun, 28 Jan 2018 10:15:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.223.184.10 with SMTP id h10ls797663wrf.0.gmail; Sun, 28 Jan 2018 10:15:46 -0800 (PST) X-Received: by 10.28.236.24 with SMTP id k24mr16718027wmh.8.1517163346318; Sun, 28 Jan 2018 10:15:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517163346; cv=none; d=google.com; s=arc-20160816; b=WGzjtcxGegNols8b9vPm+gMtUZh1gxe3sJkFvX90k3lnm3XIknIW/rKlCvIBmycy/1 PMwesGYQcFaVq0d68c+Y/66HSCgpv9GwJ66p36g8GSKrva0QwwubtSwOM3huUSlsVCwy nTeXFe3p+IaiH7qS+4g2H0AMyELM/EJUHgq0T4FflSl4NBHu4TbhKaZaLyAlT21ajkpK X8GyR1ENVwA1c222Vk+l9Rbd8neMT6Btu60OozxSLVZM2a9a4J5+u9NtgMXbndA2KaR6 jsahcVcPmF6BiW2m/NXAZt+il9Mbleb58FgkdKKoFF1XVBL8tH8XgVHgc7GVvSbijrQ5 MQMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=FA3hTE6OGo7w/hlkL4p2l/PN95sHMmmCacQIW8ihAq4=; b=vxMyRCU+NgDjfK3+8mKpCDBbjpMw7NHXMIy0axtFAlnlJccoko5EBOS84J5Szwad1L p5bBlZ5seNOioaKc44FxVdZJz64nepuDBffFh88vsToF/TV2OyB4FPYjcQiO0H5WROJ6 pnRFLaAbbTcGlEXkUlAWBwqoxBH/AObBDUQ9r/AJKdv8yDcD1ndA5xNNLLtuc4ZVFFXF dYYs4Y7a0GoKBiTCgjC+VbWQFGJogYwXrf5A8qnq4MAIZ5epRkWosh6CZXWNyyuP2P+e hzjELBKK8eAhGhQVsFDAr9SzGJhWrAfVzmhjmSUsfhO7u+zQbkNH4aHRsL9M3LIWkb++ mDAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dGpZIRxP; spf=pass (google.com: domain of bastienpenava@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=bastienpenava@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id w19sor5340281wra.52.2018.01.28.10.15.46 for (Google Transport Security); Sun, 28 Jan 2018 10:15:46 -0800 (PST) Received-SPF: pass (google.com: domain of bastienpenava@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 10.223.142.99 with SMTP id n90mr4356400wrb.100.1517163345681; Sun, 28 Jan 2018 10:15:45 -0800 (PST) Original-Received: by 10.223.135.76 with HTTP; Sun, 28 Jan 2018 10:15:45 -0800 (PST) In-Reply-To: <437c4139-06b9-4751-aa2f-dea9563266dd@isocpp.org> X-Original-Sender: BastienPenava@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dGpZIRxP; spf=pass (google.com: domain of bastienpenava@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=bastienpenava@gmail.com; dmarc=pass (p=NONE sp=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:36757 Archived-At: --f403045d5aec4921080563da1ef6 Content-Type: text/plain; charset="UTF-8" 2018-01-28 16:29 GMT+01:00 Nicol Bolas : > On Sunday, January 28, 2018 at 12:26:25 AM UTC-5, bastie...@gmail.com > wrote: >> >> Hi, >> >> So I was toying with the idea of named tuple when I remembered D's name >> resolution operator >> and check if >> it was possible to implement in C++. >> For those not familiar to the idea it's manly an operator that receives >> the unknown member access as a template non-type parameter instead of >> causing an error. >> To my surprise it is an is quite cheap to implement (50 lines for GCC) >> and could quite powerful (particularly if combined with reflection). >> To avoid creating a new operator i'm using the operator* with a template >> non-type reference parameter as the 'new' operator :* template> memberName> auto operator*();* >> One of the motivations to use this operator is because it allows >> out-of-class definitions. >> You can try and check some exemple here if you wish : >> http://dispatch.gcc-future.tk/# >> >> The reason why I bring this up is that I believe that It could solve a >> bunch of demands that have been unsuccessful in the past (generally due to >> their coast being to great compared to the supposed benefit. ie: new >> operator, keyword, syntax, etc...). >> Mainly the dot operator, properties, out of class method definition and >> UCS. >> >> Here are a few examples. >> >> logging class with reflection: >> > > This doesn't work on constructors/destructors. Or operators, unless the > caller spelled out the operator name (maybe?). > Yes indeed it wouldn't. It could but i don't think that would be a good thing. > > properties, simulate inheritance, multiple names: >> > > I've seen a* lot* of syntaxes proposed for properties, but that is > perhaps the worst. The fact that you have to declare all of the properties > inside of a single function makes this a hideous beast if your class has a > significant number of properties. > I agree, it would quite hideous but you're not required to define everything inside one function. Instead of using "if constexpr" you can redeclare the function with a different requirement on the ids you want. That being able to regroup everything inside > > standard layout, pod: >> > > std::complex doesn't need help being standard layout. It's already > required to be standard layout, and with a very specific layout. Nobody is > stopping you from having `real` and `img` member functions with that layout. > Woow I'm not claiming such a thing at all. I just used this example to illustrate that it can allow for properties on trivial/pod types without changing the definition. > > Out of class method definition / templated this / UCS: >> > > We definitely do not want people to be able to inject methods into > arbitrary classes like this. Besides, how would you find this operator? ADL > is how out-of-member operators are normally found. > The point of UCS is just that isn't it ? Using the member access syntax call on normal functions. UCS could be implemented on the library side with this and reflection with a static operator defined in an header . For the question I don't understand what you mean. It a normal operator it's just that it is called as a fallback when a member access fails due to the member not being found. There is no complexity to it. > -- > You received this message because you are subscribed to a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit https://groups.google.com/a/ > isocpp.org/d/topic/std-proposals/fFwL0jskVUA/unsubscribe. > To unsubscribe from this group and all its topics, 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/437c4139-06b9-4751- > aa2f-dea9563266dd%40isocpp.org > > . > -- 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/CAOhm51ETF9sL%2BpUnec%2Bbkt256LZOOX-y5PzaiX1Fr86PZpDtpw%40mail.gmail.com. --f403045d5aec4921080563da1ef6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-01-28 16:29 GMT+01:00 Nicol Bolas <jmckesson@gmail.com><= /span>:
On Sunday, January 28, 2018 at 12:26:25 AM UTC-5, bastie...@gmail.com wrote:
Hi,

So I wa= s toying with the idea of named tuple when I remembered D's name resolution operator=C2=A0and check if it was p= ossible to implement in C++.
For those not familiar to the idea i= t's manly an operator that receives the unknown member access as a temp= late non-type parameter instead of causing an error.
To my surpri= se it is an is quite cheap to implement (50 lines for GCC) and could quite = powerful (particularly if combined with reflection).
To avoid cre= ating a new operator i'm using the operator* with a template non-type r= eference parameter as the 'new' operator : template<auto&= memberName> auto operator*();
One of the motivations to u= se this operator is because it allows out-of-class definitions.
Y= ou can try and check some exemple here if you wish :=C2=A0http://dispat= ch.gcc-future.tk/#

The reason why I b= ring this up is that I believe that It could solve a bunch of demands that = have been unsuccessful in the past (generally due to their coast being to g= reat compared to the supposed benefit. ie: new operator, keyword, syntax, e= tc...).
Mainly the dot operator, properties, out of class method = definition and UCS.

Here are a few examples.
=

logging class with reflection:
=

This doesn't work on constructors/destructor= s. Or operators, unless the caller spelled out the operator name (maybe?).<= /div>
Yes indeed it wouldn't. It could but i don= 't think that would be a good thing.=C2=A0

properties, simulate inheritan= ce, multiple names:

= I've seen a lot of syntaxes proposed for properties, but that is= perhaps the worst. The fact that you have to declare all of the properties= inside of a single function makes this a hideous beast if your class has a= significant number of properties.
I agree, it= would quite hideous but you're not required to define everything insid= e one function.
Instead of using "if constexpr" you can= redeclare the function with a=C2=A0 different requirement on the ids you w= ant.
That being able to regroup everything inside=C2=A0

standard layout, pod:

std::complex doesn't need help bei= ng standard layout. It's already required to be standard layout, and wi= th a very specific layout. Nobody is stopping you from having `real` and `i= mg` member functions with that layout.
Woow I&= #39;m not claiming such a thing=C2=A0 at all. I just used this example to i= llustrate that it can allow for properties on trivial/pod types without cha= nging the definition.
=

Out of class method definition / templated this / UCS:

We definitely do not want people to be able= to inject methods into arbitrary classes like this. Besides, how would you= find this operator? ADL is how out-of-member operators are normally found.=
The point of UCS is just that isn't it ? = Using the member access syntax call on normal functions.
UCS coul= d be implemented on the library side with this and reflection with a static= operator defined in an header <ucs>.

For th= e question I don't understand what you mean. It a normal operator it= 9;s just that it is called as a fallback when a member access fails due to = the member not being found. There is no complexity to it.


--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/f= FwL0jskVUA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-prop= osals+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/437c= 4139-06b9-4751-aa2f-dea9563266dd%40isocpp.org.

--
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/CAOhm51ETF9sL= %2BpUnec%2Bbkt256LZOOX-y5PzaiX1Fr86PZpDtpw%40mail.gmail.com.
--f403045d5aec4921080563da1ef6-- .