220 27573 article Path: news.gmane.org!.POSTED!not-for-mail From: "'Johannes Schaub' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: this in non-member functions Date: Wed, 3 Aug 2016 20:03:58 +0200 Lines: 74 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1470247450 2449 195.159.176.226 (3 Aug 2016 18:04:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 3 Aug 2016 18:04:10 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCQPNCEZSQNBBD7ERC6QKGQEIP4YLKQ@isocpp.org Wed Aug 03 20:04:06 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f200.google.com ([209.85.223.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bV0WP-00086u-Hb for gclcip-std-proposals@m.gmane.org; Wed, 03 Aug 2016 20:04:01 +0200 Original-Received: by mail-io0-f200.google.com with SMTP id i199sf461462524ioi.2 for ; Wed, 03 Aug 2016 11:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references: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=g8gKSIFI9FUGW58wm495iechBpPrF6udyjHZWdJS6Rk=; b=MUvfNwGDLpLaQ5nozq48SVM6LE209UR9qOpm0OwA4KlbS62vunlEhgZjOs8/h6E9kz IxGVo9hL0ZDMtTxqWiyst/Uc8gopTvKUPz40tDjChPijkkMzPyo+Gq8AXBe/MRCHCeCK ScYBvuw3schEAI7ES5KIIEvvyEHmDDTlRSh6iVOK2OVUpRbgYCmkmnZNPWcfkExZ0+ci SDf7ZYqFPRzCPrJdxfPszcUIWBl1dcWJYU9vDmTjKyVErCvDyBLjVzT44A7khuteg5er xPSt8+W1G5kO3nQPBw6tPQJ8MsP+F3oGG5DEM4err+CbZXOE8iWvKWWOgwo19ixyn+nj nzMg== 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: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=g8gKSIFI9FUGW58wm495iechBpPrF6udyjHZWdJS6Rk=; b=BMzK/7ENbAU4sr40TBysNTXJ+87DTF6YkT+qYkNhHY8fghIuf8l85kczzpwh9jp+6z 7aBbLj1C8wmgvHoLWQaGujllHHwXLPPkcetadvcPhp2LEa38OwFOobN/lfRciwg9Qic+ 0dRv11gZG4Sn8MCqacKdfj5OVb0C12X31cCbnWPQe/WJsds8iALsQ2JOqhR42NW95zQI 76XrOduxdTUwOn5VlQFeBSCIivDrHkx6XTG4WBtmvQeyHU8itXgBItNPlWDmyjJKwJsx sSzN/L5Lsr60WQeMOc/dz2meMTPpOHAEX5a3IFU0VlxXRYcLB8csbT3xXG+1OzSwF+R7 cS+g== X-Gm-Message-State: AEkoousv+nlM2OEYGuTwcOh4m1u0cII00+LVDiitiHt3fM5aMR4hwSp0PtdAsERwzfGykA== X-Received: by 10.157.44.38 with SMTP id f35mr2263512otb.14.1470247440362; Wed, 03 Aug 2016 11:04:00 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.151.10 with SMTP id z10ls790012iod.31.gmail; Wed, 03 Aug 2016 11:03:59 -0700 (PDT) X-Received: by 10.107.155.82 with SMTP id d79mr74312649ioe.36.1470247439206; Wed, 03 Aug 2016 11:03:59 -0700 (PDT) Original-Received: from mail-io0-x235.google.com (mail-io0-x235.google.com. [2607:f8b0:4001:c06::235]) by mx.google.com with ESMTPS id 67si9273398ioj.72.2016.08.03.11.03.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Aug 2016 11:03:59 -0700 (PDT) Received-SPF: pass (google.com: domain of schaub.johannes@googlemail.com designates 2607:f8b0:4001:c06::235 as permitted sender) client-ip=2607:f8b0:4001:c06::235; Original-Received: by mail-io0-x235.google.com with SMTP id q83so251204121iod.1 for ; Wed, 03 Aug 2016 11:03:59 -0700 (PDT) X-Received: by 10.107.152.201 with SMTP id a192mr78280266ioe.24.1470247438767; Wed, 03 Aug 2016 11:03:58 -0700 (PDT) Original-Received: by 10.107.16.38 with HTTP; Wed, 3 Aug 2016 11:03:58 -0700 (PDT) In-Reply-To: X-Original-Sender: schaub.johannes@googlemail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@googlemail.com; spf=pass (google.com: domain of schaub.johannes@googlemail.com designates 2607:f8b0:4001:c06::235 as permitted sender) smtp.mailfrom=schaub.johannes@googlemail.com; dmarc=pass (p=QUARANTINE dis=NONE) header.from=googlemail.com X-Original-From: Johannes Schaub 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:27573 Archived-At: I would propose an "expression reinterpret cast", which reinterprets any expression that matches a passed pattern within its body. "[rule]" refers to a grammar rule and "" to a captured grammar rule. So, this would be reinterpret_cast([unqualified-id], this-><1>) { m = 1; // equivalent: this->m = 1; } 2016-08-03 11:58 GMT+02:00 Viacheslav Usov : > 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. -- 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/CANu6V4X6jDVVuuvyN8P47ojxds%3DkpORey23i%2BKzhrWh3%3DG1L1w%40mail.gmail.com. .