220 12667 article Path: news.gmane.org!not-for-mail From: Zhihao Yuan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Templated *this Date: Wed, 3 Sep 2014 22:12:23 -0400 Lines: 229 Approved: news@gmane.org Message-ID: References: <574eee30-46d0-433f-b572-65b6844e2d8e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="047d7b343a4c1b2091050233e20e" X-Trace: ger.gmane.org 1409796756 683 80.91.229.3 (4 Sep 2014 02:12:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Sep 2014 02:12:36 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCSKRWMD4EHBBDEVT6QAKGQEM3JFDVA@isocpp.org Thu Sep 04 04:12:31 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XPMXG-000540-8y for gclcip-std-proposals@m.gmane.org; Thu, 04 Sep 2014 04:12:30 +0200 Original-Received: by mail-ie0-f199.google.com with SMTP id tr6sf48485885ieb.10 for ; Wed, 03 Sep 2014 19:12:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:sender:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=/InppuiZKU52Dczuyk2KbmdSrlKJV1xLj2PAcWI7cp8=; b=VaRhhjw8XfZapKxqCQhqSmPRYGoL1W5p3/9YDZWQoZdY8hwwU6bX1uYoQYv+e91HX8 2evCj2Ai25lcjoet45WX4sN8FpXOtmH2N3dfL/EcKHfjTamufbEN0om5EFmlZqvS5s7o YkuXLX76P5kguG/byxY0ZAjTGwzWcyocDe3ulr2r8Hy43GoTOiz168kkPoOwMWQHGKOf rrnkMMy6G8dk8GL9JjyzJQltYL0/ZwFQMtrw73KeVKG0DMwO3nxpLDLcmIB4FovLISDj A8CNlEZrT6ANH+eKk1K4zhZ4yeAZEkvNodEzrhnoyXW/X5ZavYJpBg760zMAcgn1wS6r IfhA== X-Gm-Message-State: ALoCoQlBb1jKZotLwTHvJkCPUdUlX5DKtpeYHkZN5LqzNvWMj4PjLiD/yQPdxCRalPLK7qT2tWyJ X-Received: by 10.182.43.164 with SMTP id x4mr837814obl.5.1409796749392; Wed, 03 Sep 2014 19:12:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.16.112 with SMTP id 103ls104662qga.9.gmail; Wed, 03 Sep 2014 19:12:28 -0700 (PDT) X-Received: by 10.220.44.80 with SMTP id z16mr952362vce.7.1409796748688; Wed, 03 Sep 2014 19:12:28 -0700 (PDT) Original-Received: from mail-s68.mailgun.info (mail-s68.mailgun.info. [184.173.153.196]) by mx.google.com with ESMTPS id c11si2155240vdj.97.2014.09.03.19.12.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Sep 2014 19:12:28 -0700 (PDT) Received-SPF: pass (google.com: domain of bounce+3f9131.69110-std-proposals=isocpp.org@miator.net designates 184.173.153.196 as permitted sender) client-ip=184.173.153.196; Original-Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by mxa.mailgun.org with ESMTP id 5407ca8a.7f568c9acc70-in2; Thu, 04 Sep 2014 02:12:26 -0000 (UTC) Original-Received: by mail-vc0-f178.google.com with SMTP id la4so10080552vcb.9 for ; Wed, 03 Sep 2014 19:12:23 -0700 (PDT) X-Received: by 10.220.166.68 with SMTP id l4mr1032905vcy.20.1409796743567; Wed, 03 Sep 2014 19:12:23 -0700 (PDT) Original-Received: by 10.220.40.5 with HTTP; Wed, 3 Sep 2014 19:12:23 -0700 (PDT) Original-Received: by 10.220.40.5 with HTTP; Wed, 3 Sep 2014 19:12:23 -0700 (PDT) In-Reply-To: <574eee30-46d0-433f-b572-65b6844e2d8e@isocpp.org> X-Mailgun-Sid: WyI3MTBkYiIsICJzdGQtcHJvcG9zYWxzQGlzb2NwcC5vcmciLCAiNjkxMTAiXQ== Original-Sender: zy@miator.net X-Original-Sender: zy@miator.net X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of bounce+3f9131.69110-std-proposals=isocpp.org@miator.net designates 184.173.153.196 as permitted sender) smtp.mail=bounce+3f9131.69110-std-proposals=isocpp.org@miator.net; dkim=pass header.i=@miator.net 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:12667 Archived-At: --047d7b343a4c1b2091050233e20e Content-Type: text/plain; charset=UTF-8 I saw that, but that is OK as a meta-programming, while I don't think the problem of const and perfect forwarding member function should require user to go that far. And, these two features can coexist. On Sep 3, 2014 9:57 PM, "Matthew Fioravante" wrote: > There was another discussion here about possibly inventing a new syntax > for templating qualifiers (const, volatile, ref) but keeping the underlying > type fixed. That's a much harder problem, but if solved it would also solve > your problem here as well. > > > https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/oFglS6zn8ik > > > On Wednesday, September 3, 2014 3:16:06 PM UTC-4, Zhihao Yuan wrote: >> >> We know the difficulty of writing both const and non-const >> member functions, and one suggestion was made in this >> mailing list, which is to make const qualifier conditional >> like noexcept. Meanwhile I have another idea which can >> be used to solve the problem, plus another issue I'm going >> to state below. >> >> Member function with reference qualifier does not benefit >> from reference collapsing. To write a function doing perfect >> forwarding, you have to have a template argument T&& >> >> template >> void f(T&& v); >> >> since reference collapsing requires template argument >> deduction, but member function has no such thing for *this. >> >> Actually, the natural of the problem of `const` is as same as >> this one. If it's a free function, >> >> template >> void f(T& v); >> >> will work for both Type& and Type const&, but we have no >> `T` for *this. >> >> So how about making the type of *this into a template? >> (I know, it's always lvalue, but I can't find a better term for >> now.) >> >> template // bikeshedding time >> void f() T&; // A& or A const& >> >> template >> void f() T&&; // A& or A&&, etc >> >> Problem solved, AFAICS. >> >> One more thing, several months ago I found it's very annoying >> to write recursive member function with rvalue reference >> qualifier: >> >> struct A { >> void f() && { >> f(); // does not compile >> // try std::move(*this).f() >> } >> }; >> >> Because the implicit (*this) is treated as a lvalue, even in >> a member function for rvalue. With my suggestion you can >> write std::forward(*this).f() but that's not my point... >> To implement my suggestion, you have to be able to >> distinguish the value category of *this, so why not redefine >> the "implicit this rule" in template *this function to to make >> the following code work? >> >> template >> void f() T&& >> { >> f(); >> } >> >> Comments are welcome. >> >> -- >> Zhihao Yuan, ID lichray >> The best way to predict the future is to invent it. >> ___________________________________________________ >> 4BSD -- http://bit.ly/blog4bsd >> > -- > > --- > 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 > http://groups.google.com/a/isocpp.org/group/std-proposals/. > -- --- 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 http://groups.google.com/a/isocpp.org/group/std-proposals/. --047d7b343a4c1b2091050233e20e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I saw that, but that is OK as a meta-programming, while I do= n't think the problem of const and perfect forwarding member function s= hould require user to go that far.=C2=A0 And, these two features can coexis= t.

On Sep 3, 2014 9:57 PM, "Matthew Fioravante= " <fmatthew5876@gmail.com= > wrote:
There was another discussion here about possibly inventing= a new syntax for templating qualifiers (const, volatile, ref) but keeping = the underlying type fixed. That's a much harder problem, but if solved = it would also solve your problem here as well.

https://groups.google.com/a/isocpp.or= g/forum/#!topic/std-proposals/oFglS6zn8ik


On Wed= nesday, September 3, 2014 3:16:06 PM UTC-4, Zhihao Yuan wrote:
We know the d= ifficulty of writing both const and non-const
member function= s, and one suggestion was made in this
mailing list, which is to make co= nst qualifier conditional
like noexcept.=C2=A0 Meanwhile I have another idea which can
=
be used to solve the problem, plus another issue I'm goingto state below.

Member function with reference qualifie= r does not benefit
from reference collapsing.=C2=A0 To write a function doing perfect
forwa= rding, you have to have a template argument T&&

= =C2=A0 template <typename T>
=C2=A0 void f(T&& = v);

since reference collapsing requires template argumentdeduction, but member function has no such thing for *this.

=
Actually, the natural of the problem of `const` is as same as
this one.=C2=A0 If it's a free function,

=C2=A0 template <typename T>
=C2=A0 void= f(T& v);

will work for both Type& and Type const= &, but we have no
`T` for *this.

So how= about making the type of *this into a template?
(I know, it's always lvalue, but I can't find a better term for
= now.)

=C2=A0 template <this T>=C2=A0 // bikesheddin= g time
=C2=A0 void f() T&;=C2=A0 // A& or A const&= ;

=C2=A0 template <this T>
=C2=A0 void f() T&&= ;;=C2=A0 // A& or A&&, etc

Problem solved, AF= AICS.

One more thing, several months ago I found it's= very annoying
to write recursive member function with rvalue reference
qualifier:
<= /div>
=C2=A0 struct A {
=C2=A0 =C2=A0 void f() && {
=C2=A0= =C2=A0 =C2=A0 f();=C2=A0 // does not compile
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 // try std::move(*this).f()
=C2=A0=C2=A0=C2=A0 }
=C2=A0 };

Because the implicit (*this)= is treated as a lvalue, even in
a member function for rvalue.=C2=A0 Wit= h my suggestion you can
write std::forward<T>(*this).f() but= that's not my point...
To implement my suggestion, you have to be able to
distinguish the= value category of *this, so why not redefine
the "implicit t= his rule" in template *this function to to make
the following= code work?

=C2=A0 template <this T>
=C2=A0 void f() T&&am= p;
=C2=A0 {
=C2=A0=C2=A0=C2=A0 f();
=C2=A0 }

Comments are welcome.

--
Zhihao Yuan, ID lichray
The best way to predict the future is= to invent it.
__________________________________________________= _
4BSD -- http://bi= t.ly/blog4bsd

--

---
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/gro= up/std-proposals/.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--047d7b343a4c1b2091050233e20e-- .