220 6000 <3aa5744a-a7f7-4d28-af92-983f73601a01@isocpp.org> article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal: Mixins for C++ Date: Thu, 29 Aug 2013 23:19:57 -0700 (PDT) Lines: 144 Approved: news@gmane.org Message-ID: <3aa5744a-a7f7-4d28-af92-983f73601a01@isocpp.org> References: <787081f7-fb40-4507-907d-259318ef2000@isocpp.org> <1c80b902-4e65-4f4b-a5d7-8953dbf6df05@isocpp.org> <8ab6e544-6db0-45ee-9827-f19f59e00317@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_332_2399213.1377843597595" X-Trace: ger.gmane.org 1377843599 18721 80.91.229.3 (30 Aug 2013 06:19:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Aug 2013 06:19:59 +0000 (UTC) Cc: cornedbee@google.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBD7TQCIQKGQELHQMBHY@isocpp.org Fri Aug 30 08:20:02 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f199.google.com ([209.85.214.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VFI3s-0001Y7-Lw for gclcip-std-proposals@m.gmane.org; Fri, 30 Aug 2013 08:20:00 +0200 Original-Received: by mail-ob0-f199.google.com with SMTP id dn14sf5466294obc.2 for ; Thu, 29 Aug 2013 23:19:59 -0700 (PDT) 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=0IcX9hFQ/Bx+zuNeAXDsFpUHTNaO1HP1vRgpa3uQ3do=; b=DkB8AI7sLOthXl9yawEK8jdUAz+qx4U+M6Bl/NcuwGxiOTgx4JwKq4wYMdsupK7Bdq San6R5EMm73jnKbjIfr15+08oW6OwnB49c4n1QwSLyQC1s3mIYtzxE5D622YbQslehcZ HGm8eDbzEqT24nfvX+PKDKPbhP8xih6OAmFyIiJFgeQWaHKRV8iA9mQ59pdzZWWO9YDG 4LjQGtN66RU2iXIEyjq6o1ZC7sma1axXd3J8994251CT5GfM28y8RRwArIgTtN8VWQBU 0pL7qaJz1Uxl6AEdPLoE1SM0xhH2uAudVf4VZF1CkzTAVo3ONDgQhU6FR6V95RMyg17Z f2bA== X-Received: by 10.50.107.37 with SMTP id gz5mr1141645igb.1.1377843599670; Thu, 29 Aug 2013 23:19:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.62.44 with SMTP id v12ls253111igr.43.gmail; Thu, 29 Aug 2013 23:19:59 -0700 (PDT) X-Received: by 10.50.6.98 with SMTP id z2mr50187igz.0.1377843599111; Thu, 29 Aug 2013 23:19:59 -0700 (PDT) In-Reply-To: <8ab6e544-6db0-45ee-9827-f19f59e00317@isocpp.org> X-Original-Sender: potswa@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:6000 Archived-At: ------=_Part_332_2399213.1377843597595 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, August 28, 2013 8:07:11 PM UTC+8, corn...@google.com wrote: > > On Wednesday, August 28, 2013 1:21:09 PM UTC+2, David Krauss wrote: > >> Some new syntax would be required to run the constructor of the mixin. It >> would be odd to mention a name from a using declaration in a constructor >> mem-initializer. >> > > It's not a using declaration. It's a using mixin directive. ;-) > > Yes, mixins can have constructors and destructors so that they can maintain > their own invariants. And yes, I fully intend them to be called from the > initializer list of the embedding class, using the mixin's name, mingled > with the member variables of the class. I don't see why that's unintuitive, > and especially not how new syntax would be any better. > Often the invariants for members are not established by the first line of the constructor body. A mixin depending on some functionality in the host class would expect invariants for the host members its constructor accesses. The host class would in the general case need to call the mixin's constructor from its body. The same actually goes for destructors: the host destructor needs to relinquish the mixin at some point in its execution, not before beginning or after ending. Maybe I'm making something out of nothing. There can always be initializeand finalize methods in addition to the constructor and destructor. Moving the calls of the constructor and destructor would wreak havoc with object lifetimes. On the other hand, being able to defer initialization of a member whose constructor arguments require more preparation than can be accomplished in the mem-initializer-list would work around a longstanding issue. All we really need after all is to make UB use before initialization. > Recently I suggested inferring member declarations from a concept applied >> to a template parameter used as a base class. A name that is required to >> exist doesn't really need to be considered type-dependent. Applied to an >> incomplete class, the principle could help bridge the gap that seems to be >> causing confusion in the above posts. Not to make a blanket judgment about >> this proposal, but CRTP can probably be improved by such relatively minor >> changes. >> > > Using concepts on the parameter of a CRTP base - interesting idea. I'm not > sure how concept checks would work for incomplete types, though. > Concepts are applicable to any template parameter, and tolerating an incomplete argument is generally considered to be a good thing. There should be a modifier, applicable to any concept parameter declaration, that defers the check until an incomplete class type is completed. (I just figured this out now, should start a new thread. Thanks for the impetus!) -- --- 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_332_2399213.1377843597595 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wednesday, August 28, 2013 8:07:11 PM UTC+8, corn..= ..@google.com wrote:

On Wednesday, August 28, 2013 1:21:09 PM UTC+2, David Krauss = wrote:
Some new= syntax would be required to run the constructor of the mixin. It would be = odd to mention a name from a using declaration in a constructor mem-initial= izer.

It's not a using declaratio= n. It's a using mixin directive. ;-)
 
<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">
Yes, mixi= ns can have constructors and destructors so that they can maintain their ow= n invariants. And yes, I fully intend them to be called from the initialize= r list of the embedding class, using the mixin's name, mingled with the mem= ber variables of the class. I don't see why that's unintuitive, and especia= lly not how new syntax would be any better.
Often the invariants for members are not established by the first line of= the constructor body. A mixin depending on some functionality in the host = class would expect invariants for the host members its constructor accesses= .. The host class would in the general case need to call the mixin's constru= ctor from its body. The same actually goes for destructors: the host destru= ctor needs to relinquish the mixin at some point in its execution, not befo= re beginning or after ending.

Maybe I'm making something out of noth= ing. There can always be finalize methods in addition to the constructor and destructor. Mov= ing the calls of the constructor and destructor would wreak havoc with obje= ct lifetimes.

On the other hand, being able to defer initialization = of a member whose constructor arguments require more preparation than can b= e accomplished in the mem-initializer-list would work around a longstanding= issue. All we really need after all is to make UB use before initializatio= n.
 
Recently I su= ggested inferring member declarations from a concept applied to a template = parameter used as a base class. A name that is required to exist doesn't re= ally need to be considered type-dependent. Applied to an incomplete class, = the principle could help bridge the gap that seems to be causing confusion = in the above posts. Not to make a blanket judgment about this proposal, but= CRTP can probably be improved by such relatively minor changes.
<= /blockquote>
 
Using concepts on the parameter of a CRTP= base - interesting idea. I'm not sure how concept checks would work for in= complete types, though.

Concepts are appli= cable to any template parameter, and tolerating an incomplete argument is g= enerally considered to be a good thing. There should be a modifier, applica= ble to any concept parameter declaration, that defers the check until an in= complete class type is completed. (I just figured this out now, should star= t a new thread. Thanks for the impetus!)

--
 
---
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_332_2399213.1377843597595-- .