220 1538 <25f46407-5644-4edb-a20a-cb77064dddb8@isocpp.org> article Path: news.gmane.org!not-for-mail From: Michael Price - Dev Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: making using declaration more precise Date: Tue, 8 Jan 2013 19:05:17 -0800 (PST) Lines: 160 Approved: news@gmane.org Message-ID: <25f46407-5644-4edb-a20a-cb77064dddb8@isocpp.org> 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_2268_82902.1357700717381" X-Trace: ger.gmane.org 1357700720 10565 80.91.229.3 (9 Jan 2013 03:05:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jan 2013 03:05:20 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC63BP4Z2YBRB4F4WODQKGQEFC7GYCI@isocpp.org Wed Jan 09 04:05:38 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ye0-f199.google.com ([209.85.213.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Tslyy-00015b-HY for gclcip-std-proposals@m.gmane.org; Wed, 09 Jan 2013 04:05:36 +0100 Original-Received: by mail-ye0-f199.google.com with SMTP id l12sf2200796yen.2 for ; Tue, 08 Jan 2013 19:05:20 -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=mElfBWHjwM3k+NRVH15Zp+9CJ9h0VSEuJ3OOpimu6II=; b=QiSHAut+6/QEimBdAPSDNW2Dks+Qh17LH4AYWCiOaZ7wjPLjY4KwkKo6sVtJq80AYg shZksLmIyvWTc0Zyn60mzKPaj3l9viq2s4Fv0CbpiI5APBIhvUwlKpgdGTi7JKKuuK3k Euo2+KmXVrY1cVMRAg2yI8Yfzd2vDDACVWNazEK/oOJxlnramakajCoz717l769FNzjD VdN/RvKSj9l3AW7AR6zJ5I2gbJ2gUSZcbQ78314H37QxQcG9yy4A7N9TenLv9gMD6niO 6hOtfn3ItlSXabkQgfRU1p/LXISQVYCl3UhYQHoE9YT86KXWb9RqcKAVOTv7mM2IgQ0P mIaw== X-Received: by 10.224.190.193 with SMTP id dj1mr41628404qab.6.1357700720369; Tue, 08 Jan 2013 19:05:20 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.82.70 with SMTP id g6ls757125qey.33.gmail; Tue, 08 Jan 2013 19:05:18 -0800 (PST) X-Received: by 10.49.81.72 with SMTP id y8mr11942329qex.42.1357700718720; Tue, 08 Jan 2013 19:05:18 -0800 (PST) In-Reply-To: <738f626c-3b23-4c74-9eea-2c2246921a81@isocpp.org> X-Original-Sender: michael.b.price.dev@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:1538 Archived-At: ------=_Part_2268_82902.1357700717381 Content-Type: text/plain; charset=ISO-8859-1 I've mentioned it briefly once before on this list (several months ago) that I have a similar idea that would include something like this but in a larger context of function aliasing. When the using-keyword is used to change the accessibility of a base type's member, it is like we are creating an alias in the current type's scope for the base type's member. I'd like to generalize that idea to allow for the following types of things - defining a simple forwarding function (pass each parameter onto either a base method or a method of a member - mapping the interface for one type to the interface of another (similar to concept maps, but less "concepty") - optionally allowing parameter reordering for forwarding functions - using methods from a base class A to satisfy the virtual method requirements from a second base class B - making it easier to swap out implementations for free-standing functions (similar to type name aliasing tricks) - perhaps eliminating the practice of using function pointers for aliasing where the pointed-to-function is known at compile-time and never changes. I believe that Nicol's concerns about changing interfaces is real (I've seen it happen), and is in fact one of the driving forces behind the final/override syntax for polymorphic types. This would bring that same capability to non-virtual types (perhaps even with similar syntax) Ville's example of a forwarding function is a simple (but common) one. There are "nastier" examples in real-world code though. I'm not quite ready to begin an official proposal document for these ideas, but would be more than willing to partner with others that might be interested. I'd guess that minus the technical specifications, incorporating all of these ideas would be a rather lengthy proposal and I would also consider breaking it into smaller ones if it helped get any piece through the standardization process. On Saturday, January 5, 2013 12:07:03 PM UTC-6, 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. > > -- ------=_Part_2268_82902.1357700717381 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've mentioned it briefly once before on this list (several months ago) tha= t I have a similar idea that would include something like this but in a lar= ger context of function aliasing.

When the using-keyword= is used to change the accessibility of a base type's member, it is like we= are creating an alias in the current type's scope for the base type's memb= er.  I'd like to generalize that idea to allow for the following types= of things
  • defining a simple forwarding function (pass ea= ch parameter onto either a base method or a method of a member
  • = mapping the interface for one type to the interface of another (similar to = concept maps, but less "concepty")
  • optionally allowing paramete= r reordering for forwarding functions
  • using methods from a base= class A to satisfy the virtual method requirements from a second base clas= s B
  • making it easier to swap out implementations for free-stand= ing functions (similar to type name aliasing tricks)
  • perhaps elimin= ating the practice of using function pointers for aliasing where the pointe= d-to-function is known at compile-time and never changes.
I believe that Nicol's concerns about changing interfaces is real (I've = seen it happen), and is in fact one of the driving forces behind the final/= override syntax for polymorphic types.  This would bring that same cap= ability to non-virtual types (perhaps even with similar syntax)  Ville= 's example of a forwarding function is a simple (but common) one.  The= re are "nastier" examples in real-world code though.

I'm not quite ready to begin an official proposal document for these ide= as, but would be more than willing to partner with others that might be int= erested.  I'd guess that minus the technical specifications, incorpora= ting all of these ideas would be a rather lengthy proposal and I would also= consider breaking it into smaller ones if it helped get any piece through = the standardization process.

On Saturday, January 5, 2013 12:= 07:03 PM UTC-6, 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 blu= nt and not very precise tool, which could be quite easily tweaked.
What= I mean is:

class A
{
public:<= /div>
void f();
void f(int);
};

<= /div>
class B: public A
{
using A::f;//here we cann= ot make a choice on which one we would like to use in our B class, which so= metimes is ok...
};

but in scenario:
class A
{
void f(int);
public:
void f();
};

class B :public A
<= div>{
using A::f;//will not compile even though the only fnc we w= ant is A::f()
};

What I would like to pr= opose 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 wan= t 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.

--
 
 
 
------=_Part_2268_82902.1357700717381-- .