220 36756 <437c4139-06b9-4751-aa2f-dea9563266dd@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: meta members: a 0+ cost properties & dot operator Date: Sun, 28 Jan 2018 07:29:56 -0800 (PST) Lines: 154 Approved: news@gmane.org Message-ID: <437c4139-06b9-4751-aa2f-dea9563266dd@isocpp.org> References: <11f9c7ff-aa76-46a5-94b2-0692171ab0ff@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8569_522868792.1517153396815" X-Trace: blaine.gmane.org 1517153294 9638 195.159.176.226 (28 Jan 2018 15:28:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Jan 2018 15:28:14 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB5OYW7JQKGQEIHSDDHA@isocpp.org Sun Jan 28 16:28:10 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1efos6-0001J1-Ae for gclcip-std-proposals@m.gmane.org; Sun, 28 Jan 2018 16:27:54 +0100 Original-Received: by mail-ua0-f197.google.com with SMTP id f5sf2233519ual.18 for ; Sun, 28 Jan 2018 07:29:59 -0800 (PST) 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=+118IGtT3alEiA7O0Pl8H0Sucg7t5gR41LsMEXbeDcU=; b=1oXiwVK5E9dCBuIrOaSjXQIJsFOLoAKphBPXZbqnygCjqW3qyPLXYqpTQKWbdO4fxv aisoYquA+pze17hQsznLIWpX/8k5tDvFl2ow856+ZRdHlOhiaHwrMO+Z7dUqCa5W6ust 0AqSOThfpXeibhronBuw5nOSgVHDbScZ8sZ+qSAlWtvjfJkTxB/aLK8dmzD6rNLINZ8g 7fu0XSNo+hiFTb63gxBYOcM+TCWpX/XOk+tD3jn3LneKdelYQJ7SrZJiiPaPI42f5tOs WVq+QjaQQ1nQzICgEzTEVTDd8W+S7zdbO+9UzoU0pe68F9Gt7w3YXwQDVzpavG+THZfu F/ug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=+118IGtT3alEiA7O0Pl8H0Sucg7t5gR41LsMEXbeDcU=; b=Ea0Ug4Bt0+xjOs7Qxmd8pBxbaQz2SHHYpt6Gy/GHAPNRJdnSaFJ9iXc484xU84tTJT uV0+7n/otMNpgIC0wMXbvjMum8TgeQ7m2eC0yovyztZ0+0OP+vAzlTr7irDahZ/3bckd Gb2VWsmWNE2mFSH9vSH5IiiB4sdSaMJrxx3gjxbwVoz++QO4+mUz1bjaUfHHKaWz/HRO m0SgVh81xsrsRtwkgCSU+dK7kWkf4uxZhFifeSGKZG0bmZ1ieHUkDhZ50omfCqZqKKZq yWLZOLpHBxO4MxMJhG4SirYC31/NgYNvmeONmBQMij860KtMaD3TyqgP3vCOEu+dYl2x 4iTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=+118IGtT3alEiA7O0Pl8H0Sucg7t5gR41LsMEXbeDcU=; b=sTIY+Mwgbwr9BHPHSh7MOpI/Zojsd++IC5eJXZ8LoResW4FFbJ99uUx99kzaAvWTiv Ht4VxHHZgBXRzSQArOlBMZxXLc8OIkB4NddiTMEZHTEqlcuLZqtQbP3NZ/idJ0cxt4S7 e1TxLEUbxgMIKAzE165irDNWyWxS9ISME5LpQhwsWKtrYN9PasVknH3C+wcEAlQkqSzr AWDrJ5LzDv6B7muuy219Bs2krbnDvxOCOLUI4n+mXgmwcXyFrXF7UEACfjGvCII2J+60 JDssu2SIeobViDq/4dQ1HMHErESu9zQJj1pVMyXKT/4zvr+FBRq+iHC2DO/QyD+3aW0F xhWA== X-Gm-Message-State: AKwxytcUlMTGqZW+ZKUAegBwEhBNTd7T6dhuYcIFsEa82ibuXTrMqy+F D4NfDGTLpH6eHxeMeSxfHqe8vw== X-Google-Smtp-Source: AH8x227C84SNvZ3kaQQBrI1BAiDL/XTUOTp4xPbzm+t1p6rY6M2HcJH1dd1X2JTIYCRD1HaNpyId1w== X-Received: by 10.176.93.194 with SMTP id l2mr10292752uag.85.1517153398934; Sun, 28 Jan 2018 07:29:58 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.48.5 with SMTP id f5ls2367610ual.6.gmail; Sun, 28 Jan 2018 07:29:57 -0800 (PST) X-Received: by 10.31.3.215 with SMTP id f84mr1721286vki.9.1517153397284; Sun, 28 Jan 2018 07:29:57 -0800 (PST) In-Reply-To: <11f9c7ff-aa76-46a5-94b2-0692171ab0ff@isocpp.org> X-Original-Sender: jmckesson@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:36756 Archived-At: ------=_Part_8569_522868792.1517153396815 Content-Type: multipart/alternative; boundary="----=_Part_8570_549408834.1517153396815" ------=_Part_8570_549408834.1517153396815 Content-Type: text/plain; charset="UTF-8" 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?). 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. 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. 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. -- 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/437c4139-06b9-4751-aa2f-dea9563266dd%40isocpp.org. ------=_Part_8570_549408834.1517153396815 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 wh= en I remembered D's name resolution operator=C2=A0= and check if it was possible to implement in C++.
For those not f= amiliar to the idea it's manly an operator that receives the unknown me= mber 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<auto& memberName> auto operator*();
One of= the motivations to use this operator is because it allows out-of-class def= initions.
You can try and check some exemple here if you wish := =C2=A0http://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: ne= w operator, keyword, syntax, etc...).
Mainly the dot operator, pr= operties, out of class method definition and UCS.

= Here are a few examples.

logging class with reflec= tion:

This doesn't work on = constructors/destructors. Or operators, unless the caller spelled out the o= perator name (maybe?).

properties, simulate inheritance, multip= le names:

I've seen a lot of syntaxes proposed for properties, but that is perhaps the wors= t. The fact that you have to declare all of the properties inside of a sing= le function makes this a hideous beast if your class has a significant numb= er of properties.

standard layout, pod:

std::complex doesn't need help being standard layo= ut. It's already required to be standard layout, and with a very specif= ic layout. Nobody is stopping you from having `real` and `img` member funct= ions with that layout.

<= div dir=3D"ltr">
Out of class method definition / templated this / UCS:=

We definitely do not want peop= le 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 no= rmally found.

--
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/437c4139-06b9-4751-aa2f-dea9563266dd= %40isocpp.org.
------=_Part_8570_549408834.1517153396815-- ------=_Part_8569_522868792.1517153396815-- .