220 8071 article Path: news.gmane.org!not-for-mail From: Andrew Tomazos Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal: Private extension methods Date: Mon, 9 Dec 2013 19:26:26 -0800 (PST) Lines: 168 Approved: news@gmane.org Message-ID: References: <05028bfb-6f6f-4ee8-9a6e-7e6eaa3a877a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_57_6428257.1386645986683" X-Trace: ger.gmane.org 1386645986 15151 80.91.229.3 (10 Dec 2013 03:26:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Dec 2013 03:26:26 +0000 (UTC) Cc: fmatthew5876@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD5KHQXXWYPRBY4TTKKQKGQEVXCNBOY@isocpp.org Tue Dec 10 04:26:30 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f200.google.com ([209.85.192.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VqDxt-0005hz-Pz for gclcip-std-proposals@m.gmane.org; Tue, 10 Dec 2013 04:26:30 +0100 Original-Received: by mail-pd0-f200.google.com with SMTP id p10sf20675803pdj.7 for ; Mon, 09 Dec 2013 19:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=dpnoblygu3esRheK/a7BRFAeiAfSkTMnsXZKb+p3pbw=; b=rnyEjmORC2AXo+sie+zAfmca3lN3tuL12F4lXaER+KoBs3kNacjx2gYdjtADyBQXRd H3VbB1x7z7RqrfJEWcYYqSS1FKDjhNaFSqfahnwD4TZZnci5p6LM1bL0JjvNpkddoeR4 hHkd+1OFdbakDeGwmpjDXXpdgS3wnwqGrP0ZyprlL+QH776+bGkk9nWxVOHxR0OID6Mn DKmBAee4KGj32qoouLXa6BgN+1s4y3oZYqBJhAac7ZEG7bdkxzCdyF5OM+LXjRqXum0f 2tN5QoMtuCZ5yYZjjAZZZiwIcdfFMFo9JXIUWWot7pTDUZp+9bnYLNW7QJ05erInlHM3 opFQ== 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:cc: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=dpnoblygu3esRheK/a7BRFAeiAfSkTMnsXZKb+p3pbw=; b=YePXm6qhUhuruH+kkuZpeUY7EYOXl8n/ZuF5r/8SG/efGzXItxqdPd7wHV9+2aE2Lv UbG3BWVDYHSKmLqIzqcyG64NvmyQ5Zcqve87zyzv4Z/CW3sVsjC+HncyDwyOCjkhOCNW Q0K3bfiNK2m2j0iZvgIdBwLAtS3km4w7XVrlnKA6Zcdl/Za0q5rOZT7zMwZxVlSpCiNk 3/h14mnF/8E/GEBk3rYxSO2ygNxt7f2UQdWkfXv0rGJXJtGQ4Q0kjW/QTPhBj9GMcARx 7ESCiEA3Uzhqoq+63IstYofXWW26ZlHQ8zIJ6tlA7MekF4gbwU2tZrQ0ljwhUd9ozZyJ 2+2w== X-Gm-Message-State: ALoCoQkPj3dPEBgRVJ45f2uHZKYC/pF2O9KpyTmjaNpRCa9RYbIEU3R37lwxcJTY4nb92pRn1p0x X-Received: by 10.66.150.106 with SMTP id uh10mr11954315pab.13.1386645988659; Mon, 09 Dec 2013 19:26:28 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.19.165 with SMTP id g5ls1076916obe.59.gmail; Mon, 09 Dec 2013 19:26:27 -0800 (PST) X-Received: by 10.182.28.100 with SMTP id a4mr62655obh.28.1386645987829; Mon, 09 Dec 2013 19:26:27 -0800 (PST) In-Reply-To: <05028bfb-6f6f-4ee8-9a6e-7e6eaa3a877a@isocpp.org> X-Original-Sender: andrewtomazos@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:8071 Archived-At: ------=_Part_57_6428257.1386645986683 Content-Type: text/plain; charset=ISO-8859-1 Hi Matthew, I did briefly read your proposal. You touch on this a little in your proposal, but just to be clear 9.4p5 [class.static]: > When used in the declaration of a class member, the static specifier shall only be used in the member declarations that appear within the member-specification of the class definition. So this is currently ill-formed: struct X { void f(); }; static void X::f() {} // ERROR This frees the static specifier up to be used to specify a static member function if that is what you want. There is no ambiguity with the internal linkage meaning on a free function. In the event someone accidentally places static in front of a private extension method, intending internal linkage but getting a static member function, then the only effect is a compile-time error when they try to access the implicit object parameter that doesn't exist. It isn't dangerous. You might also want to consider giving private extension methods implicit internal linkage (both static and non-static member functions), the only use case I can imagine is placing them in the .cpp so the linker doesn't even need to see the symbol, and if you really do want them to have external linkage you can always declare them in the class specifier as normal. Your proposal breaks a current rule that a qualified declarator id has to be declared unqualified previously in the TU. This might cause a minor hassle to implementors with name lookup on declarator ids during parsing. I think the main resistance you will receive is from people that claim that this would break encapsulation. Currently the only entities that can access private members are all declared in the class specifier (either as members or friends). Some will claim that this is a nice property for programming in the large, as you can isolate what can be messing with private data to a list of possible culprits all in one place. A private extension method, on the other hand, can be declared anywhere in the codebase. I'm however on your side fwiw, and think that having private member functions not cluttering the class specifier outweighs the loss. Also you might want to spend some time studying the interaction with template classes. I assume you can also define private extension methods of template classes too? How will they interact with specialization/instantiation? Good luck, Andrew. On Tuesday, December 10, 2013 3:20:46 AM UTC+1, fmatth...@gmail.com wrote: > > Hello everyone, I am going to submit a proposal for relaxing the > restriction on requiring private non-virtual class methods and static > private class methods to be declared in the class definition. > > The github repository with the current draft of the proposal is here: > https://github.com/fmatthew5876/stdcxx-privext > > The proposal came out of the discussion from this thread: > > https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/private/std-proposals/xukd1mgd21I/akgZSTG4NBUJ > > -- --- 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_57_6428257.1386645986683 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Matthew,

I did briefly read your pro= posal.

You touch on this a little in your proposal= , but just to be clear 9.4p5 [class.static]:

> W= hen used in the declaration of a class member, the static specifier shall o= nly be used in the member declarations that appear within the member-specif= ication of the class definition.

So this is curren= tly ill-formed:

struct X
{
&nb= sp;   void f();
};

static void X::f= () {} // ERROR

This frees the static specifier up = to be used to specify a static member function if that is what you want. &n= bsp;There is no ambiguity with the internal linkage meaning on a free funct= ion.  In the event someone accidentally places static in front of a pr= ivate extension method, intending internal linkage but getting a static mem= ber function, then the only effect is a compile-time error when they try to= access the implicit object parameter that doesn't exist.  It isn't da= ngerous.

You might also want to consider giving pr= ivate extension methods implicit internal linkage (both static and non-stat= ic member functions), the only use case I can imagine is placing them in th= e .cpp so the linker doesn't even need to see the symbol, and if you really= do want them to have external linkage you can always declare them in the c= lass specifier as normal.

Your proposal breaks a c= urrent rule that a qualified declarator id has to be declared unqualified p= reviously in the TU.  This might cause a minor hassle to implementors = with name lookup on declarator ids during parsing.

I think the main resistance you will receive is from people that claim tha= t this would break encapsulation.  Currently the only entities that ca= n access private members are all declared in the class specifier (either as= members or friends).  Some will claim that this is a nice property fo= r programming in the large, as you can isolate what can be messing with pri= vate data to a list of possible culprits all in one place.  A private = extension method, on the other hand, can be declared anywhere in the codeba= se.  I'm however on your side fwiw, and think that having private memb= er functions not cluttering the class specifier outweighs the loss.

Also you might want to spend some time studying the inter= action with template classes.  I assume you can also define private ex= tension methods of template classes too?  How will they interact with = specialization/instantiation?

Good luck,
Andrew.


On Tuesday, December 10, 2013 3:20:46 = AM UTC+1, fmatth...@gmail.com wrote:
Hello everyone, = I am going to submit a proposal for relaxing the restriction on requiring p= rivate non-virtual class methods and static private class methods to be dec= lared in the class definition.

The gith= ub repository with the current draft of the proposal is here:
=


--
 
---
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/group/std-proposals/<= /a>.
------=_Part_57_6428257.1386645986683-- .