220 12668 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:17:33 -0400 Lines: 299 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="001a1136ad728e4e88050233f4ed" X-Trace: ger.gmane.org 1409797069 4503 80.91.229.3 (4 Sep 2014 02:17:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Sep 2014 02:17:49 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCSKRWMD4EHBBQUXT6QAKGQEVNCN35A@isocpp.org Thu Sep 04 04:17:43 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XPMcG-00009c-CC for gclcip-std-proposals@m.gmane.org; Thu, 04 Sep 2014 04:17:40 +0200 Original-Received: by mail-ob0-f198.google.com with SMTP id wp18sf49390167obc.1 for ; Wed, 03 Sep 2014 19:17:39 -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=28bKmxjTvP8J/nP0YaGijO4b4IGG7ziHBP38gHyNTdg=; b=cTKH7pd9pUrjOvdUfMFJQ9v0CrMt7f9XK3rmr/SBFYipvg9FeYEkoRNxsYaxZXBm1n kgH5SIFIfiJUjXz9sil3rIXoX5mVFWxCGUkwRjnBT7zPf/jelg331EHJGyylL4PTZr0H ebyOPF3Fu82CZj7DI41yOjT00bSvCwJe/sFdWqcclXdndBr//3V16UshM1sBZuhcX34O mKY5rDUFIs0aLjFgJIu9MT8kqqr4E+9xdrf6BADo52cPi+latjTGWVGLXzTV2U3qbjrs atvuThtUwIJfcJjrNgT5E+GXStN2gT3ctFmShwRCRHOLS3T5cz5MMrrGzl0YziuM1MP2 uXZg== X-Gm-Message-State: ALoCoQk01p29AdTwEqCeKvBLSqem6TWjnSOlgUZHJFqzXr438Zztv2KIvYuAljCRtk9qXgTcDtO2 X-Received: by 10.182.130.168 with SMTP id of8mr817773obb.27.1409797059474; Wed, 03 Sep 2014 19:17:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.98.99 with SMTP id n90ls90908qge.66.gmail; Wed, 03 Sep 2014 19:17:37 -0700 (PDT) X-Received: by 10.220.172.8 with SMTP id j8mr1036155vcz.32.1409797057321; Wed, 03 Sep 2014 19:17:37 -0700 (PDT) Original-Received: from mail-s68.mailgun.info (mail-s68.mailgun.info. [184.173.153.196]) by mx.google.com with ESMTPS id gx1si4926119vcb.61.2014.09.03.19.17.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Sep 2014 19:17:37 -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-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by mxa.mailgun.org with ESMTP id 5407cbbd.67584f0-in3; Thu, 04 Sep 2014 02:17:33 -0000 (UTC) Original-Received: by mail-vc0-f170.google.com with SMTP id la4so9889391vcb.15 for ; Wed, 03 Sep 2014 19:17:33 -0700 (PDT) X-Received: by 10.52.61.136 with SMTP id p8mr813217vdr.15.1409797053105; Wed, 03 Sep 2014 19:17:33 -0700 (PDT) Original-Received: by 10.220.40.5 with HTTP; Wed, 3 Sep 2014 19:17:33 -0700 (PDT) Original-Received: by 10.220.40.5 with HTTP; Wed, 3 Sep 2014 19:17:33 -0700 (PDT) In-Reply-To: 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:12668 Archived-At: --001a1136ad728e4e88050233f4ed Content-Type: text/plain; charset=UTF-8 I missed this one. I understand the current limitation of *this, but I'm arguing that we should have a "new" *this which has a context dependent value category, so that we can make simple things easy to do, by using a plain parameterized type, as simple as a free function, instead of something more complex than that, including template-templates. On Sep 3, 2014 10:01 PM, "Richard Smith" wrote: > I made a suggestion in the original thread too: > > > https://groups.google.com/a/isocpp.org/d/msg/std-proposals/3RygF_VV098/yaxZizFg_SsJ > > On Wed, Sep 3, 2014 at 6: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/. > -- --- 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/. --001a1136ad728e4e88050233f4ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I missed this one.

I understand the current limitation of *this, but I'm ar= guing that we should have a "new" *this which has a context depen= dent value category, so that we can make simple things easy to do, by using= a plain parameterized type, as simple as a free function, instead of somet= hing more complex than that, including template-templates.

On Sep 3, 2014 10:01 PM, "Richard Smith&quo= t; <richard@metafoo.co.uk&g= t; wrote:
I made a suggestion in the original thread too:

https://groups.google.com/a/isocpp.org/d/msg/std-propo= sals/3RygF_VV098/yaxZizFg_SsJ

On Wed, Sep 3, 2014 at 6:57 PM, Matthew Fior= avante <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 Wednesday, September 3, 2014 3:16:06 PM UTC-4, Zhihao Yua= n 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-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>.
--001a1136ad728e4e88050233f4ed-- .