220 1492 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: making using declaration more precise Date: Mon, 7 Jan 2013 13:18:06 -0800 (PST) Lines: 163 Approved: news@gmane.org Message-ID: References: <738f626c-3b23-4c74-9eea-2c2246921a81@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2014_5742179.1357593486946" X-Trace: ger.gmane.org 1357593488 7138 80.91.229.3 (7 Jan 2013 21:18:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Jan 2013 21:18:08 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBEPXVSDQKGQE4PYWKDQ@isocpp.org Mon Jan 07 22:18:26 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f200.google.com ([209.85.216.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TsK5R-0003ho-CH for gclcip-std-proposals@m.gmane.org; Mon, 07 Jan 2013 22:18:25 +0100 Original-Received: by mail-qc0-f200.google.com with SMTP id l42sf30423872qco.11 for ; Mon, 07 Jan 2013 13:18:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:date:from:to:message-id :in-reply-to:references:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=yL5EB0qsU8k1Ooog/1dV+6T0+bInagA3Bk0Sr/F5XB8=; b=QdVC3RvPglC5WBKzyyj0IX40QwCA/9E4nzYCdn1lEYpvNWaKT3IN4vx1KgQt12437y +QhvG0e9fs2a5zqD4gkVO/rUf+uvjVu1QzcFLPaWVJEkOI1zd2iMSW0Z7SjL6uv+AZBa kZ+eh5btVOEJEKD7im1QPmTN006ZeqB0zqco66/hzEJrAtVs63rpMiXr4GCJtDCIm/8C 8w+4BVWGzvXqfO0334PamRvOHKdNvbS71iauPQlsFNKLP2yb+qJGdjJbByz+/RjvVReQ I/tdTY30od3UcEEn6CcRBonQtQb7KOccbhJrqfOaPYmfHWe9GsA7h8vLEYUHhU1VP5gm rG+Q== X-Received: by 10.224.190.193 with SMTP id dj1mr38290713qab.6.1357593489402; Mon, 07 Jan 2013 13:18:09 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.24.37 with SMTP id r5ls8885993qef.85.gmail; Mon, 07 Jan 2013 13:18:08 -0800 (PST) X-Received: by 10.49.39.99 with SMTP id o3mr10595144qek.14.1357593488223; Mon, 07 Jan 2013 13:18:08 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@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:1492 Archived-At: ------=_Part_2014_5742179.1357593486946 Content-Type: text/plain; charset=ISO-8859-1 On Monday, January 7, 2013 11:08:05 AM UTC-8, Ville Voutilainen wrote: > > On 5 January 2013 20:07, Arthur Tchaikovsky > > wrote: > > I wonder if anyone feels the same as me about using declaration while > > specifying members from base class? As things are now, it is very blunt > and > > not very precise tool, which could be quite easily tweaked. > > What I mean is: > > class A > > { > > public: > > void f(); > > void f(int); > > }; > > class B: public A > > { > > using A::f;//here we cannot make a choice on which one we would like to > use > > in our B class, which sometimes is ok... > > }; > > but in scenario: > > class A > > { > > void f(int); > > public: > > void f(); > > }; > > class B :public A > > { > > using A::f;//will not compile even though the only fnc we want is A::f() > > }; > > What I would like to propose is following backwards compatible syntax: > > class B :public A > > { > > using A::f;//here I'm specifying that I want use every fnc 'f' from A - > just > > like before, but this will not compile > > using A::f();//here I explicitly specify which fnc I want to use > > }; > > The use case which is I believe compelling is the one that if function f > > overloaded and one or more is declared private, this actively prohibits > us > > from the use of any other, non-private functions 'f' from the base > class. > > Looking forward to comments. > > The work-around would, I think, be > > class B :public A > { > void f(int x) {A::f(x);} > }; > > Adding the new syntax doesn't seem to be compelling compared to the > very low cost > of specifying exactly the signatures you want and calling the base > implementation of them. > It's not as maintainable. If the syntax in `A` changes, you don't get a proper compiler error if the syntax happens to remain compatible with the old one. If they change `f(int)` to `f(int64_t)` or something, the compiler will silently let this work. With the proposed syntax, if there is no `f(int)` in the base class, it fails to compile. Which forces everyone to update to the new syntax. It's also a lot more obvious what's going on. -- ------=_Part_2014_5742179.1357593486946 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Monday, January 7, 2013 11:08:05 AM UTC-8, Ville Voutilainen wro= te:
On 5 January 2013 20:07, Ar= thur Tchaikovsky <atch...@gmail.com> wrote:
> I wonder if anyone feels the same as me about using declaration wh= ile
> specifying members from base class? As things are now, it is very = blunt and
> not very precise tool, which could be quite easily tweaked.
> What I mean is:
> class A
> {
> public:
> void f();
> void f(int);
> };
> class B: public A
> {
> using A::f;//here we cannot make a choice on which one we would li= ke to use
> in our B class, which sometimes is ok...
> };
> but in scenario:
> class A
> {
> void f(int);
> public:
> void f();
> };
> class B :public A
> {
> using A::f;//will not compile even though the only fnc we want is = A::f()
> };
> What I would like to propose is following backwards compatible syn= tax:
> class B :public A
> {
> using A::f;//here I'm specifying that I want use every fnc 'f' fro= m A - just
> like before, but this will not compile
> using A::f();//here I explicitly specify which fnc I want to use
> };
> The use case which is I believe compelling is the one that if func= tion f
> overloaded and one or more is declared  private, this activel= y prohibits us
> from the use of any other, non-private functions 'f' from the base= class.
> Looking forward to comments.

The work-around would, I think, be

class B :public A
{
   void f(int x) {A::f(x);}
};

Adding the new syntax doesn't seem to be compelling compared to the
very low cost
of specifying exactly the signatures you want and calling the base
implementation of them.

It's not as maintainable. If the syntax in `A` ch= anges, you don't get a proper compiler error if the syntax happens to remai= n compatible with the old one. If they change `f(int)` to `f(int64_t)` or s= omething, the compiler will silently let this work.

With the propose= d syntax, if there is no `f(int)` in the base class, it fails to compile. W= hich forces everyone to update to the new syntax. It's also a lot more obvi= ous what's going on.

--
 
 
 
------=_Part_2014_5742179.1357593486946-- .