220 12896 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: unevaluated this Date: Mon, 15 Sep 2014 14:06:18 -0700 Lines: 96 Approved: news@gmane.org Message-ID: References: <009e6218-1e2b-402d-ab1a-e8ebf29f8f77@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113403d0955c46050321014b X-Trace: ger.gmane.org 1410815189 7579 80.91.229.3 (15 Sep 2014 21:06:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Sep 2014 21:06:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDVNBJG4YAIBBS5J3WQAKGQEI42AKKQ@isocpp.org Mon Sep 15 23:06:22 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XTdTY-00013O-Qr for gclcip-std-proposals@m.gmane.org; Mon, 15 Sep 2014 23:06:21 +0200 Original-Received: by mail-oi0-f70.google.com with SMTP id i138sf16770941oig.9 for ; Mon, 15 Sep 2014 14:06:19 -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:sender:in-reply-to:references:date :message-id:subject:from:to: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=jZRKIkpNUJRN+ussE3gkQMPiGF5BZptfN0DpSKlrmAM=; b=JM4MMnU427XqcjTV8tj1a1U42BCRzUZGD8svyLN83z3aF0mU94Vm4LP03dPnU5EWhF YrXlXu1Ek+fbrHvW7Ble/spObFVbIjhakXfQsMZYJ9LCLYvUjb6xwxpmWQdKDEcOgrN4 JcBg46DtmwHy/WnoAgXF0fWH1uqlEJuEnMxsJ4ggQpmderFqL36x+NsjQ2GRoD9HOU7v 2fj828oeKD5Dpg+CVnsDnu512oOg+EfHAgac8kWl4WeTFkmXwBW5BkQOnLr/EHTYnumV ItIRsqt1q9c8a1sLDMoHtbNCqIRyKrNnVv4AFa4CyN27+x+7uSiKDBCxBzb/j9quonWU Fw+w== X-Gm-Message-State: ALoCoQnnPcD+pcaSaH1AwcYZY3SqqFj9dEXOdvQsmnM+vuHGJSebSMvlFNAG4RXA4lZvd8hEQldk X-Received: by 10.42.188.210 with SMTP id db18mr17798867icb.9.1410815179861; Mon, 15 Sep 2014 14:06:19 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.18.193 with SMTP id 59ls1674157qgf.7.gmail; Mon, 15 Sep 2014 14:06:19 -0700 (PDT) X-Received: by 10.220.169.2 with SMTP id w2mr25799273vcy.33.1410815179016; Mon, 15 Sep 2014 14:06:19 -0700 (PDT) Original-Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [2607:f8b0:400c:c03::236]) by mx.google.com with ESMTPS id dc6si3691727vdc.36.2014.09.15.14.06.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Sep 2014 14:06:19 -0700 (PDT) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c03::236 as permitted sender) client-ip=2607:f8b0:400c:c03::236; Original-Received: by mail-vc0-f182.google.com with SMTP id le20so4098571vcb.13 for ; Mon, 15 Sep 2014 14:06:18 -0700 (PDT) X-Received: by 10.52.61.99 with SMTP id o3mr21631735vdr.46.1410815178921; Mon, 15 Sep 2014 14:06:18 -0700 (PDT) Original-Sender: metafoo@gmail.com Original-Received: by 10.220.76.200 with HTTP; Mon, 15 Sep 2014 14:06:18 -0700 (PDT) In-Reply-To: <009e6218-1e2b-402d-ab1a-e8ebf29f8f77@isocpp.org> X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c03::236 as permitted sender) smtp.mail=metafoo@gmail.com; dkim=pass header.i=@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:12896 Archived-At: --001a113403d0955c46050321014b Content-Type: text/plain; charset=UTF-8 On Mon, Sep 15, 2014 at 9:17 AM, Sean Middleditch < sean.middleditch@gmail.com> wrote: > Another proposal carrying on from work I did earlier. This is a > continuation of the decltype(class) feature I suggested some time back but > with Ville's suggestion taken to heart. It's now a proposal for allowing > `this` in unevaluated contexts (decltype, sizeof, etc.) anywhere in a class > definition body or base specifier list as well as a convenient helper > `std::this_t`. > > > http://htmlpreview.github.io/?https://github.com/seanmiddleditch/CPlusPlus/blob/master/unevaluated-this.html > > Thoughts/comments/critiques would be appreciated. Thanks! > This seems dangerous to me; it gets cv-qualifiers wrong. Consider: struct S { decltype(this) f() const; auto g() const -> decltype(this); }; Note that f() returns S*, and g() returns const S*. The current restrictions on where 'this' can appear are not related to where we can get a value for it, they're simply the set of places where it has a meaningful type. Your use cases all appear to be 'get the current class type', not 'get the type of a pointer to the current instance, with missing cv-qualifiers in some cases', so I don't see that 'this' is the right thing to be going after. Given that your std::this_t doesn't work, what's wrong with decltype(this)? -- --- 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/. --001a113403d0955c46050321014b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Sep 15, 2014 at 9:17 AM, Sean Middleditch <sean.middleditch@g= mail.com> wrote:
Another proposal carrying on from work I did earlier. This is a co= ntinuation of the decltype(class) feature I suggested some time back but wi= th Ville's suggestion taken to heart. It's now a proposal for allow= ing `this` in unevaluated contexts (decltype, sizeof, etc.) anywhere in a c= lass definition body or base specifier list as well as a convenient helper = `std::this_t`.

=
Thoughts/comments/critiques would be appreciated. Thanks!

This seems dangerous to me; it ge= ts cv-qualifiers wrong. Consider:

=C2=A0 struct S = {
=C2=A0 =C2=A0 decltype(this) f() const;
=C2=A0 =C2=A0= auto g() const -> decltype(this);
=C2=A0 };

Note that f() returns S*, and g() returns const S*. The current res= trictions on where 'this' can appear are not related to where we ca= n get a value for it, they're simply the set of places where it has a m= eaningful type.

Your use cases all appear to be &#= 39;get the current class type', not 'get the type of a pointer to t= he current instance, with missing cv-qualifiers in some cases', so I do= n't see that 'this' is the right thing to be going after. Given= that your std::this_t doesn't work, what's wrong with decltype(thi= s)?

--

---
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>.
--001a113403d0955c46050321014b-- .