220 27549 article Path: news.gmane.org!.POSTED!not-for-mail From: Viacheslav Usov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: this in non-member functions Date: Wed, 3 Aug 2016 11:58:15 +0200 Lines: 107 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1141024249b2b2053927df4a X-Trace: blaine.gmane.org 1470218303 31407 195.159.176.226 (3 Aug 2016 09:58:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 3 Aug 2016 09:58:23 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBDU6VRPKW4BBBOMAQ66QKGQEBRNP3YQ@isocpp.org Wed Aug 03 11:58:18 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f71.google.com ([74.125.82.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bUswM-0007ns-09 for gclcip-std-proposals@m.gmane.org; Wed, 03 Aug 2016 11:58:18 +0200 Original-Received: by mail-wm0-f71.google.com with SMTP id 1sf121579093wmz.2 for ; Wed, 03 Aug 2016 02:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=TiPMn8btl61nbHqWyJAFYngYqVB3JD8lXwF9vm0O5Yg=; b=cLxQoXhW9Aq8WrKCzzIt62MYL34ag9S1AAvObp30BjUgL+cQBrkRRWA6NLJbTDVfeh WVR8lR3JYsePWluurUUYHn+HI2v5txeRx5nsY9wyUItGUoJ+KundtPwZwgFvSafgkwtl BWskJ2llg3xkpoYIRLAVOI94r9DChxZTd3i2MQQi5imPMPz5MMckOSAt13ahGzWWeGib bZuCm7qmmJSFnbrqoKJGkQvPMY6KuiVtu0vDdaDDLASLM53Kllvlszd0vlZ61PhL8NNo L3tuCnyrSdmqXFgqFcY0bqovC4dKbB3qp6vLIByDVkkB+EuedSzrhJXM/9gohUsrI4mt EJAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=TiPMn8btl61nbHqWyJAFYngYqVB3JD8lXwF9vm0O5Yg=; b=IZ64k/faFK/H+V3m4fYmPSbjLvXApnk4dJK8F5zubL//h8YtL0xPI52RuMVtMWF6Om cuY8xL4vJNNyqeaagXyPZ754ftwUv0cMaY9c46JdhyZATRBYUVk4CXMM8kLccmTBveK8 FgD/wJNoglGVIZHYEAZ2zK0AmbfFFVCzVgNupWGk9SAKqTzTuxNGQW6N2UgVQTa79AJY U/5MvTD/BtEscA1z841Ff1N4hlaxXLzfv+CKEtn/L+JOyJVqdccal9amdvBipIEkvqNB 1E202yW0cWll5mrrTpvT5zpqTSmRDqYl1B88miRPOJ/qQzZ9UVHO7mRyimDfibv6Ngol 7dag== X-Gm-Message-State: AEkoouv/oIeFwpfCWXjhvEG3GJTnHCzwPLrYesdovnOWtMPjNB9K3NLfO1c2L0lWICQH+Q== X-Received: by 10.25.141.85 with SMTP id p82mr9523269lfd.10.1470218298106; Wed, 03 Aug 2016 02:58:18 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.46.33.217 with SMTP id h86ls45131lji.47.gmail; Wed, 03 Aug 2016 02:58:16 -0700 (PDT) X-Received: by 10.25.76.139 with SMTP id z133mr21888648lfa.90.1470218296828; Wed, 03 Aug 2016 02:58:16 -0700 (PDT) Original-Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com. [2a00:1450:4010:c07::235]) by mx.google.com with ESMTPS id 203si3086434ljf.10.2016.08.03.02.58.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Aug 2016 02:58:16 -0700 (PDT) Received-SPF: pass (google.com: domain of via.usov@gmail.com designates 2a00:1450:4010:c07::235 as permitted sender) client-ip=2a00:1450:4010:c07::235; Original-Received: by mail-lf0-x235.google.com with SMTP id l69so157204809lfg.1 for ; Wed, 03 Aug 2016 02:58:16 -0700 (PDT) X-Received: by 10.25.160.15 with SMTP id j15mr21964711lfe.109.1470218296208; Wed, 03 Aug 2016 02:58:16 -0700 (PDT) Original-Received: by 10.25.214.164 with HTTP; Wed, 3 Aug 2016 02:58:15 -0700 (PDT) X-Original-Sender: via.usov@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of via.usov@gmail.com designates 2a00:1450:4010:c07::235 as permitted sender) smtp.mailfrom=via.usov@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:27549 Archived-At: --001a1141024249b2b2053927df4a Content-Type: text/plain; charset=UTF-8 Something like this may have been proposed or discussed earlier, please point me to prior work. Today the 'this' pointer is available only in member functions and lambda expressions where it is captured, explicitly or implicitly. I propose generalising this further and making it available in non-member functions, where it must be introduced via a regular declaration, either as a parameter or a local variable. In a non-member function where 'this' is declared, name lookup should work as if the function were a member of the class of 'this'. A non-member function with a declared this can still access only the public members of the class. Examples: struct A { int x; }; void foo(A *this) { x = 1; } // equivalent to this->x = 1 void bar(A *ptr) { A *this = ptr; x = 2; } // equivalent to ptr->x = 2 Open questions. A. Should we allow this to be an lvalue, i.e., after it was declared, can it be assigned a different value? A'. Note today 'this' is specified as a prvalue, which is probably the way it should stay in member functions (essentially as if it were declared via X * const this). B. Should we allow only one declaration of this per non-member function, i.e., disallow its re-declaration in nested scopes? B'. If the answer to B is no, what about member functions? Should they still not allow such re-declarations? In principle, as seen in the open questions, a more radical proposal can be made, where this could be coupled with an object per scope rather than per function, and the only distinction between member and non-member is that the former have 'this' implicitly declared as a const pointer. Cheers, V. -- 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/CAA7YVg3ObHqk-rfGRqgCqw3D-%3Du2pOwz%3Dp8NHtC6n9tpBLq-Aw%40mail.gmail.com. --001a1141024249b2b2053927df4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Something like this may have been proposed or discussed ea= rlier, please point me to prior work.

Today the 'thi= s' pointer is available only in member functions and lambda expressions= where it is captured, explicitly or implicitly.

I= propose generalising this further and making it available in non-member fu= nctions, where it must be introduced via a regular declaration, either as a= parameter or a local variable.

In a non-member fu= nction where 'this' is declared, name lookup should work as if the = function were a member of the class of 'this'. A non-member functio= n with a declared this can still access only the public members of the clas= s.

Examples:

struct A= { int x; };

void foo(A *this) { x =3D 1; } // equ= ivalent to this->x =3D 1

void bar(A *ptr) { A *= this =3D ptr; x =3D 2; } // equivalent to ptr->x =3D 2

Open questions.

A. Should we allow this to= be an lvalue, i.e., after it was declared, can it be assigned a different = value?

A'. Note today 'this' is specif= ied as a prvalue, which is probably the way it should stay in member functi= ons (essentially as if it were declared via X * const this).

=
B. Should we allow only one declaration of this per non-member f= unction, i.e., disallow its re-declaration in nested scopes?

=
B'. If the answer to B is no, what=C2=A0about member functio= ns? Should they still not allow such re-declarations?

<= div>In principle, as seen in the open questions, a more radical proposal ca= n be made, where this could be coupled with an object per scope rather than= per function, and the only distinction between member and non-member is th= at the former have 'this' implicitly declared as a const pointer.

Cheers,
V.


<= /div>

--
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/CAA7YVg3ObHqk= -rfGRqgCqw3D-%3Du2pOwz%3Dp8NHtC6n9tpBLq-Aw%40mail.gmail.com.
--001a1141024249b2b2053927df4a-- .