220 36759 <1e9a4035-1363-463a-9b97-6c153c38ebd5@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: meta members: a 0+ cost properties & dot operator Date: Sun, 28 Jan 2018 12:53:57 -0800 (PST) Lines: 347 Approved: news@gmane.org Message-ID: <1e9a4035-1363-463a-9b97-6c153c38ebd5@isocpp.org> 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/mixed; boundary="----=_Part_9096_1643667663.1517172837391" X-Trace: blaine.gmane.org 1517172721 18593 195.159.176.226 (28 Jan 2018 20:52:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Jan 2018 20:52:01 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBZXQXDJQKGQEGHLBOPA@isocpp.org Sun Jan 28 21:51:57 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eftvf-0004UR-8x for gclcip-std-proposals@m.gmane.org; Sun, 28 Jan 2018 21:51:55 +0100 Original-Received: by mail-vk0-f72.google.com with SMTP id u71sf3877698vkb.10 for ; Sun, 28 Jan 2018 12:54:00 -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=SufpBTThAXFuJjLx7IGVby4JWafQ5lqag24ONk9EgAY=; b=XspSp5zDigNlPy49PbTxggPROybBzDFMDw9QQe4NHESXHLTDRIETXp5lnoq3JHVdKd i1TIG4fiN7dwQtoIcoM2qo7h14k4HwI0Z6s8XtOtZ4JO/GuYsuR55Pqd4ENp5vpclXIM 8eqs2AMbHHK82BNJm6f4isunyCAd5D2uzQqf2c7ynU7qeZvbFMO5TJh06GPnuUuDEtQF aeHLysomdN6skjUr5Zh5F23hwTa24+e46BxwlIqzXWonVwjJ86GyY0vKlhF1L4irljB+ /KvDYf7zwGvdELmL/WM6jAfAooi6tDkbP4LIjyMRrClk6fOHCk3ZEXhwjjyFzXYu9zlE 3DRg== 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=SufpBTThAXFuJjLx7IGVby4JWafQ5lqag24ONk9EgAY=; b=GcTA9o/gsKLK8ud2A6lSwOUWI/9+iQpMihRVgYYSyGacK4CWz0k7bq5JiwS9uEYKwN eFKRZpbiP0WGlXuyzPv5Cetzj6wF2tN71Xg6rKfEmvVWkfE76h+2sET1bsV9ZB4jLXCv vQ+HHZHUI+yu0ShQGu43q4t/4mms5fI77hUnA7rk19ASN/obVaGTXEn0JzzZQLdo4XL2 HBb4mxUtvHg9/cnTY3fg//5lOx8lxjHavGrqR/tRpc5jpMHb2xvBLYieDVV+rV+J3YiA qQauy45NiIHH29N2RfKAhm5/Ed+kRxiEYBBAZNQBzs56FU2D1dx1XWcxk0jzQMgJ14Tq Ct1g== 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=SufpBTThAXFuJjLx7IGVby4JWafQ5lqag24ONk9EgAY=; b=JfbXIzMVFSrcvaX9jLXUdnM3QNFMnOPDZVuzmzt3ttpC5ggthDrOpH2ti3vHS9umL3 xQUFrQmfc5EC6poZiVsj/rVjI++6MRit8nNM3O+Xudk1WZZPWZ2Vn98O6SgBbzH029/7 yWtcg7FWm1HWIyy/Ra4cpVrsuQJjSM0VH0XGycT2HYij4fpS+AgyhYWfkbcxWl3vC0wQ pwWCqRvbbfj4aNHRnodth05e9iNf1JchiO8JWjFjD9cZZvuj/NuN3rmAgNUFQtBg4pwi QZNbqj0+9s36PEfwh+6dtDhdvBcRzH/O1G7OyI+dII2ePEPTRhHCDjeKFGd1kbFvfZKU ezKg== X-Gm-Message-State: AKwxyteg3miEvSk823a67BjP/6mUNyvWXB3F96qLtuyvo25Ejg/lHLX4 iRa2LTb3lOfGQ20Yz5tIaN5+qg== X-Google-Smtp-Source: AH8x227W0KBmL9ZUO9CeTNL3n5sx0GsH+5VoFqDFo4clK8h72a+MIeSotivdHRWSfplmvz5k/k5loQ== X-Received: by 10.176.83.74 with SMTP id y10mr10371101uay.117.1517172839750; Sun, 28 Jan 2018 12:53:59 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.5.8 with SMTP id 8ls6879315vkf.12.gmail; Sun, 28 Jan 2018 12:53:58 -0800 (PST) X-Received: by 10.31.50.209 with SMTP id y200mr2265151vky.3.1517172837853; Sun, 28 Jan 2018 12:53:57 -0800 (PST) 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-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:36759 Archived-At: ------=_Part_9096_1643667663.1517172837391 Content-Type: multipart/alternative; boundary="----=_Part_9097_1202324820.1517172837392" ------=_Part_9097_1202324820.1517172837392 Content-Type: text/plain; charset="UTF-8" On Sunday, January 28, 2018 at 1:15:48 PM UTC-5, Bastien penavayre wrote: > > 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. > If logging is important to you, why would you not want to log operators and constructors/destructors? > > 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. > Because that's so much better. > 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. > What you're talking about is about adding stuff to types* of any kind* without changing their definitions. Being "trivial/POD" has nothing to do with this. >> 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. > It depends on which version of UCS you're talking about. UCS could be implemented on the library side with this and reflection with > a static operator defined in an header . > UCS didn't fail because of the difficulty of implementing it in compilers. It failed because many people* didn't want it*. Making it theoretically writable as a library changes none of the reasons for not wanting it. And indeed, if your feature allows UCS, then that means all of those arguments against UCS become reasons not to allow your feature. 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. > My question was how do you associate a specific implementation of this `operator NAME` with an object type? Let's say you have this: struct Type {...}; Type operator+(const Type &lhs, const Type &rhs); Type t1{...}; Type t2{...}; If I do `t1+t2`, the compiler finds the `operator+` overload through the use of Argument Dependent Lookup. That is, this* only works* when the `Type` and `operator+` are in the same namespace (outside of `using` gymnastics). You cannot create a generic, template `operator+` overload that works for all types without making it a function in the global namespace (which is rude). And the same would be true of your `operator NAME` template; the only way to associate it with a particular type is to declare it in the namespace of that type. Even the member-version of UCS was based on ADL lookup (and, if I recall correctly, *only* ADL lookup. It wouldn't find functions via non-ADL means). -- 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/1e9a4035-1363-463a-9b97-6c153c38ebd5%40isocpp.org. ------=_Part_9097_1202324820.1517172837392 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, January 28, 2018 at 1:15:48 PM UTC-5, Bastien p= enavayre wrote:
2018-01-28 16:29 GMT+01:00 Nicol Bolas <jmck...@gmail.com>:
On Sunday, January 28, 2018 at 12:26:25 A= M UTC-5, bastie...@gmail.com wrote:
Hi,

So I was toying with the ide= a of named tuple when I remembered D's name resolution= operator=C2=A0and check if it was possible to implement in C++.
<= div>For those not familiar to the idea it's manly an operator that rece= ives 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 imple= ment (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&= #39; operator : template<auto& memberName> auto operator*();
One of the motivations to use this operator is because it allo= ws out-of-class definitions.
You can try and check some exemple h= ere if you wish :=C2=A0http://dispatch.gcc-future.tk/#<= br>

The reason why I bring this up is that I belie= ve that It could solve a bunch of demands that have been unsuccessful in th= e past (generally due to their coast being to great compared to the suppose= d 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:

T= his 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.

If log= ging is important to you, why would you not want to log operators and const= ructors/destructors?
=C2=A0
=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.

Because that&#= 39;s so much better.
=C2=A0
That bei= ng able to regroup everything inside=C2=A0

standard layout, pod:
<= br>
std::complex doesn't need help being standard layout. It&= #39;s already required to be standard layout, and with a very specific layo= ut. Nobody is stopping you from having `real` and `img` member functions wi= th that layout.
Woow I'm not claiming such= a thing=C2=A0 at all. I just used this example to illustrate that it can a= llow for properties on trivial/pod types without changing the definition.

What you're talk= ing about is about adding stuff to types of any kind without changin= g their definitions. Being "trivial/POD" has nothing to do with t= his.


Out of class method definition / templated this / UCS:
<= /div>

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.
The point of UCS is just that is= n't it ? Using the member access syntax call on normal functions.
=

It depends on which vers= ion of UCS you're talking about.

UCS could be implemented on the library side with this and reflectio= n with a static operator defined in an header <ucs>.

UCS didn't fail because of the = difficulty of implementing it in compilers. It failed because many people didn't want it. Making it theoretically writable as a library cha= nges none of the reasons for not wanting it. And indeed, if your feature al= lows UCS, then that means all of those arguments against UCS become reasons= not to allow your feature.

<= div>For the question I don't understand what you mean. It a normal oper= ator it's just that it is called as a fallback when a member access fai= ls due to the member not being found. There is no complexity to it.

My question was how do you= associate a specific implementation of this `operator NAME` with an object= type?

Let's say you have this:

=
struct Type
{...};

 operator+(const Type &lhs,const Type &rhs);

Type t1{...};
Type<= /span> t2<= span class=3D"styled-by-prettify" style=3D"color: #660;">{...};

If I do `t1+t2`, the compiler finds the `= operator+` overload through the use of Argument Dependent Lookup. That is, = this only works when the `Type` and `operator+` are in the same name= space (outside of `using` gymnastics).

You cannot = create a generic, template `operator+` overload that works for all types wi= thout making it a function in the global namespace (which is rude). And the= same would be true of your `operator NAME` template; the only way to assoc= iate it with a particular type is to declare it in the namespace of that ty= pe.

Even the member-version of UCS was based on AD= L lookup (and, if I recall correctly, only ADL lookup. It wouldn'= ;t find functions via non-ADL means).

--
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/1e9a4035-1363-463a-9b97-6c153c38ebd5= %40isocpp.org.
------=_Part_9097_1202324820.1517172837392-- ------=_Part_9096_1643667663.1517172837391-- .