220 5129 <74139a71-2628-485f-90fe-50597de3fdf5@isocpp.org> article Path: news.gmane.org!not-for-mail From: Jonathan Wakely Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal: Calling Base class construct on inheritance declaration Date: Wed, 19 Jun 2013 14:12:55 -0700 (PDT) Lines: 181 Approved: news@gmane.org Message-ID: <74139a71-2628-485f-90fe-50597de3fdf5@isocpp.org> References: <99414030-2563-46a3-a47b-dc43099dc74d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_627_3339347.1371676375772" X-Trace: ger.gmane.org 1371676377 25432 80.91.229.3 (19 Jun 2013 21:12:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Jun 2013 21:12:57 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCMONUNYS4IRBWF5RCHAKGQEO2JJAUQ@isocpp.org Wed Jun 19 23:12:58 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vb0-f72.google.com ([209.85.212.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UpPgX-0001Ba-SS for gclcip-std-proposals@m.gmane.org; Wed, 19 Jun 2013 23:12:58 +0200 Original-Received: by mail-vb0-f72.google.com with SMTP id p12sf7475549vbe.3 for ; Wed, 19 Jun 2013 14:12:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere: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=cUobcrpuBI2bqcQNqEY7bo4IG4j6Eors5on1V3kwMo0=; b=ILwSP4L7INkPPZRITgSFnarscEetakIADFO5TpcafTf2RdhmSBUpoG7gQkA4iJMqV9 bITMBwvk7t4JUHvAV+5wbxcQmvsg2NJp6jKXHzN9UGkD3e8eaU32E1eL9vxxpcSsMOKB nlSPMI6ckkayfW3mirJ10cD0yQc4QGX1hSSycNmBuQiVb4Y/BYo5gu2aL+1NxbgJUTZY G0E0DG0yJpHWM7AXEam836Y9M+v9HPP/wKzGL2wmBym01VBGTXRZsKRH3vnxtSEX45ls kRWHJfE5ufUKNVxpCIZZF1cUTJAGe6KJ59NP302mvITBGM5mP5Zm2TFx3k8SoLoK4yNc 7WqQ== X-Received: by 10.236.88.231 with SMTP id a67mr2311030yhf.39.1371676376944; Wed, 19 Jun 2013 14:12:56 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.24.51 with SMTP id r19ls453299qef.73.gmail; Wed, 19 Jun 2013 14:12:56 -0700 (PDT) X-Received: by 10.49.4.201 with SMTP id m9mr117413qem.15.1371676376083; Wed, 19 Jun 2013 14:12:56 -0700 (PDT) In-Reply-To: X-Original-Sender: cxx@kayari.org 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:5129 Archived-At: ------=_Part_627_3339347.1371676375772 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, June 19, 2013 8:28:39 PM UTC+1, Richard Smith wrote: > > On Wed, Jun 19, 2013 at 11:22 AM, Dan Hatch > > wrote: > > I'm looking for some feedback on whether something like this is a good > idea. > > In my opinion, it makes the code more terse and easier to understand. > > > > class Base { > > explicit Base ( const char* name ) : className( name ) {} > > const char* getClassName() { return className; } > > const char* className = "Base"; > > }; > > > > // Call Base class' constructor > > class Derived : public Base("Derived") { > > Derived( int foo ) {} > > }; > > > > // This would be syntactic sugar for calling the base class's > constructor > > for > > // each of the Derived class's constructors. > > class Derived : public Base { > > Derived() : Base("Derived") {} > > Derived( int foo ) : Base("Derived") {} > > }; > > Generally, I think this is a problem worth solving, and the implied > semantics (just like a default initializer for a non-static data > member) seem exactly right. Yes, I like the general idea. > I also like that this would fix a hole in > inheriting constructors (that you cannot specify how to construct the > other base classes). Two things here give me pause: > > 1) Default initializers were designed such that they would be parsed > within the completed class scope, behaving exactly as if they appeared > within a constructor body, and I think this proposal should aim to > harmonize with them where reasonable. It's not obvious to me whether > we would want the same delayed-parsing behavior here: if we do, it > seems surprising syntactically to be able to refer to members of the > class from before we reach the class's "{', and if we don't, we have > an unfortunate asymmetry. > > 2) The concrete syntax does not support direct-list-initialization. > For instance: > > struct A : B { /* default initializer for B base class, or class body? */ > }; > > We could disallow direct-list-initialization here (just as we disallow > direct non-list initialization for default initializers of non-static > data members), but again, the asymmetry is unfortunate. > How about a using directive at class scope, followed by a brace-or-equal-init: class Derived { using Base = "Derived"; Derived() = default; }; class Derived { using Base{"Derived"}; Derived() = default; }; The brace-or-equal-init shouldn't clash with inheriting constructors or using directives, right? -- --- 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_627_3339347.1371676375772 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wednesday, June 19, 2013 8:28:39 PM UTC+1, Richard Smith wrote:<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jun 19, 2013 at 11:22 A= M, Dan Hatch <danha...@gmail.com> wrote:
> I'm looking for some feedback on whether something like this is a = good idea.
> In my opinion, it makes the code more terse and easier to understa= nd.
>
> class Base {
>     explicit Base ( const char* name ) : className( name= ) {}
>     const char* getClassName() { return className; }
>     const char* className =3D "Base";
> };
>
> // Call Base class' constructor
> class Derived : public Base("Derived") {
>     Derived( int foo ) {}
> };
>
> // This would be syntactic sugar for calling the base class's cons= tructor
> for
> // each of the Derived class's constructors.
> class Derived : public Base {
>     Derived() : Base("Derived") {}
>     Derived( int foo ) : Base("Derived") {}
> };

Generally, I think this is a problem worth solving, and the implied
semantics (just like a default initializer for a non-static data
member) seem exactly right.

Yes, I like= the general idea.
 
I also like that this would fix a hole in
inheriting constructors (that you cannot specify how to construct the
other base classes). Two things here give me pause:

1) Default initializers were designed such that they would be parsed
within the completed class scope, behaving exactly as if they appeared
within a constructor body, and I think this proposal should aim to
harmonize with them where reasonable. It's not obvious to me whether
we would want the same delayed-parsing behavior here: if we do, it
seems surprising syntactically to be able to refer to members of the
class from before we reach the class's "{', and if we don't, we have
an unfortunate asymmetry.

2) The concrete syntax does not support direct-list-initialization.
For instance:

struct A : B { /* default initializer for B base class, or class body? = */ };

We could disallow direct-list-initialization here (just as we disallow
direct non-list initialization for default initializers of non-static
data members), but again, the asymmetry is unfortunate.


How about a using direc= tive at class scope, followed by a brace-or-equal-init:

class Derived {
  using Base =3D "Derived";
<= div>  Derived() =3D default;
};

class Derived {
  using Base{"Derived"};
  Derived() =3D default;
};

<= div>The brace-or-equal-init shouldn't clash with inheriting constructors or= using directives, right?

--
 
---
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_627_3339347.1371676375772-- .