220 12665 <574eee30-46d0-433f-b572-65b6844e2d8e@isocpp.org> article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Templated *this Date: Wed, 3 Sep 2014 18:57:39 -0700 (PDT) Lines: 177 Approved: news@gmane.org Message-ID: <574eee30-46d0-433f-b572-65b6844e2d8e@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5088_1602156432.1409795859875" X-Trace: ger.gmane.org 1409795868 21644 80.91.229.3 (4 Sep 2014 01:57:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Sep 2014 01:57:48 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBFEOT6QAKGQEW4IPBDY@isocpp.org Thu Sep 04 03:57:44 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f199.google.com ([209.85.214.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XPMIw-0003VQ-FF for gclcip-std-proposals@m.gmane.org; Thu, 04 Sep 2014 03:57:42 +0200 Original-Received: by mail-ob0-f199.google.com with SMTP id wn1sf49336070obc.2 for ; Wed, 03 Sep 2014 18:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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 :content-type; bh=AHCGESp+BSrVmYXAUWqGU9xO7ExhE83QJAMMbkPYuPo=; b=JHGjUYbJuTccLk880G4MR+Z2z3a9N2nAZ4J8ljXEGp+Td1/jFZ2y8OxWE/jt6OPGgD eQJeghdKOZ+cHu7OgYO+bF9ZgBgAGvr2IwM5EqshmQelVnHayT7dbwJ+q/KTEYh8Kpjq wKmlPdougpN1pkdJaefkPAi0fxk/SpzhVXM2yRc5mepoy9TaIWoHJQ2Fn1PYCjpnDktB Lqt644/ssXMq4shOiqhZpRVcyNAePx7pk/Oci50LL7Y75uIvyq+AYKu/HfwOn/hFeRpd CTANCGtc9y5fkdElQ0i6WL4XRRadFmx+jfT7zV9x3AcQvdtLpaQ2AqCUzxsSvQTYsE29 RGuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=AHCGESp+BSrVmYXAUWqGU9xO7ExhE83QJAMMbkPYuPo=; b=jMABUcTxOsy07AYrKJjLKshnSuMvcJ+/1zSF47daD65KVxcBNRMnFIgYqKlrMlPaFj yDHTLePJwP73tPb9NLyXcH17ycuZJxQiPmienVlnrV/wyiUDkmppAMqsCBjxjhbAP6se PgU3csQO3lOpO63+Xgo7v4b6V0lpbfX9qPlzp0+ATdYWaxqZpP58+gYGbYQm54vClnLm RA+vU/T3QIoPbPMD3/PKCFCa0m11fnmVmKNkliFEHHcKbAQan+WBzBk2YwCR9oSCfMJt p6nhKPn53NO5v53anLo+Xi0EmQMersxa1X3E5pJ+NkKsyqp8wLL+MwStuBG04PGTvCF2 sHaQ== X-Gm-Message-State: ALoCoQnX1ZSSPuXIoYVNLLDXSYXI746bWE+dhf1Ve8AtWfu0TcRiFXxVnplikyPyJSkOco7Dqy13 X-Received: by 10.42.16.69 with SMTP id o5mr795130ica.17.1409795861069; Wed, 03 Sep 2014 18:57:41 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.34.99 with SMTP id k90ls73014qgk.78.gmail; Wed, 03 Sep 2014 18:57:40 -0700 (PDT) X-Received: by 10.140.25.162 with SMTP id 31mr2685qgt.9.1409795860372; Wed, 03 Sep 2014 18:57:40 -0700 (PDT) In-Reply-To: X-Original-Sender: fmatthew5876@gmail.com 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:12665 Archived-At: ------=_Part_5088_1602156432.1409795859875 Content-Type: text/plain; charset=UTF-8 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/. ------=_Part_5088_1602156432.1409795859875 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 w= ould 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 t= his
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 do= es not benefit
from reference collapsing.  To write a function doing perfect
forwa= rding, you have to have a template argument T&&

&= nbsp; template <typename T>
  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.  If it's a free function,

  template <typename T>
  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 <this T>  // bikeshedding time
  void f() T&;  // A& or A const&

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

Problem solved, AF= AICS.

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

Because the implicit (*this)= is treated as a lvalue, even in
a member function for rvalue.  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 this r= ule" in template *this function to to make
the following code work= ?

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

Comments are welcome.

--
Zhihao Yuan, ID lichray
The best way to predict the future is= to invent it.
___________________________________________________<= br>4BSD -- http://bit.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-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>.
------=_Part_5088_1602156432.1409795859875-- .