220 17798 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: explicit[ly] require initialization of attributes Date: Mon, 11 May 2015 18:26:30 -0400 Lines: 70 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1431383213 26756 80.91.229.3 (11 May 2015 22:26:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 May 2015 22:26:53 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCO5FYHBU4ERBH6ZYSVAKGQEXKMMN5A@isocpp.org Tue May 12 00:26:45 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f199.google.com ([209.85.212.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yrw9o-00066k-UM for gclcip-std-proposals@m.gmane.org; Tue, 12 May 2015 00:26:41 +0200 Original-Received: by wizk4 with SMTP id k4sf29534602wiz.2 for ; Mon, 11 May 2015 15:26:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:date:lines:message-id:references :mime-version:content-type:user-agent:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=eBD+utNkcKevzKqAkAssnH38egYEmk5iXdw0+NxbM9o=; b=NqMx+Lv8visOQpMfkHlgRAuGEobCQBMxoaqVvSHxwdj37QIcfC74dGsWSktGG8Nkg8 uLYiiGN2lXCkfwN2RnIdpOQskiP/5TP05giQ3fIiJSo6MSKOiIYtowKBYrubX6wXD68x 5wWuAtA78aeQI1kmLUG8k385ez9nJin5T1FRYRY2P3xUHkQbwuFdnfR71nZ9g6FenhEs Ghbf10XqT9q6RbN/ju+gAv0OVa6d/jg11GjAVbcbePkPt/BI3lRYButO+ci1a/Z4MIkm qu9+RogSjxHK6XN+iQjc9lwXoN2JQYMAOzbbGJM4zx6FOhjcWVXwTbWhIujHm71bU+jO 0RVQ== X-Gm-Message-State: ALoCoQmYsArGpwEI1aWPFBNPJUogQOJjDDv3lx7xv1UmWCiBeNXN6+AUFg/79TGc8va4DXl+WBeT X-Received: by 10.194.249.1 with SMTP id yq1mr8715231wjc.2.1431383200183; Mon, 11 May 2015 15:26:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.36.227 with SMTP id t3ls706452laj.72.gmail; Mon, 11 May 2015 15:26:38 -0700 (PDT) X-Received: by 10.112.204.6 with SMTP id ku6mr9531072lbc.73.1431383198665; Mon, 11 May 2015 15:26:38 -0700 (PDT) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id pd4si9128219lbc.40.2015.05.11.15.26.38 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 11 May 2015 15:26:38 -0700 (PDT) Received-SPF: pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Yrw9l-00064o-20 for std-proposals@isocpp.org; Tue, 12 May 2015 00:26:37 +0200 Original-Received: from tripoint.kitware.com ([66.194.253.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 May 2015 00:26:37 +0200 Original-Received: from mw_triad by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 May 2015 00:26:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 61 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tripoint.kitware.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 In-Reply-To: X-Original-Sender: mw_triad@users.sourceforge.net X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) smtp.mail=gclcip-std-proposals@m.gmane.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:17798 Archived-At: On 2015-04-29 17:14, 'Matt Calabrese' via ISO C++ Standard - Future Proposals wrote: > Then my person feelings are language feature and not library feature (as in > solution 2 your original post). The library feature adds an extra level of > encapsulation and changes use of the datamember simply because a certain > constructor is not desired to be used. This requires changing code that is > unrelated to the constructor to accomodate it (I.E. code that accesses the > datamember). > > Trying to do inheritance here has a lot of issues and also doesn't > completely solve the problem. For one, it only works for things you can > inherit from (I.E. not built-in types, which is probably the most common > case that people want to account for). Further, implicit conversion still > requires change of how you access the object if you need to access an > internal datamember (I.E. .get() or -> or cast). It will also break in > subtle ways when passed to functions because it affects overload > resolution. Perhaps the most obvious case that will break is when the > wrapper object is deduced upon passing it to a template. Finally, the > wrapper object needs to forward arguments to be a complete facility, > meaning it likely needs something like an in_place facility, so even how > you invoke the constructor the object would need to be changed. All of this > just because we want a diagnositic in case we forget to initialize the > datamember. A direct language facility just seems better all around to me > if this is considered a problem that is worth solving in the standard. It sounds like what you want is a type that can choose what constructors to implement but, except in instances where it is being constructed, is treated by the compiler as if it is actually some other type 'T'. (Naturally, the compiler would in some way enforce that it exactly contains a 'T' and nothing else.) If the compiler provided a way to write such a class, this would not only solve your problem, but could also be used to "fix" types (POD's especially) that are not initialized by default construction, by implementing such an object that provides a "correct" default ctor. So, for example: explicit_init a; // error: default ctor is deleted explicit_init b{0}; // okay default_init c; // c is initialized to int{}, i.e. 0 Note that typeof(b) == typeof(c) == int. Also note that I might specialize default_init for some class T that does not initialize itself in its default ctor (e.g. Eigen matrices)... or if I am Evil, to some POD type to give it a non-standard "default" value. Such a class could not be used as a function argument, since it decays to it's wrapped type as soon as it has been constructed. This means, however, that you avoid the issues with overload resolution and the like, and also that there is zero overhead to the class (except *perhaps* a trivial overhead in the ctor, though more likely that is inlined away). Is it a good idea? I don't know. I can think of plenty of problems. On the other hand, it would potentially solve multiple problems, which might make it more attractive. -- Matthew -- --- 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/. .