220 13089 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Idea for new contextual keyword Date: Wed, 24 Sep 2014 18:37:06 -0400 Lines: 70 Approved: news@gmane.org Message-ID: References: <2ff42d9d-16df-4040-8ae1-0a17d4f78d97@isocpp.org> <0762e1e8-a99e-41c8-a96f-49fc824178ba@isocpp.org> 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 1411598252 7843 80.91.229.3 (24 Sep 2014 22:37:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Sep 2014 22:37:32 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCO5FYHBU4ERBI4PRWQQKGQEB2PAMFA@isocpp.org Thu Sep 25 00:37:25 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f197.google.com ([209.85.217.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XWvBd-00074m-4n for gclcip-std-proposals@m.gmane.org; Thu, 25 Sep 2014 00:37:25 +0200 Original-Received: by mail-lb0-f197.google.com with SMTP id l4sf5885371lbv.8 for ; Wed, 24 Sep 2014 15:37:24 -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: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:content-type; bh=B2qihgBC+8W00y7ilhLlworwaRWu21vBkL88j/Fdeq8=; b=E/ug/3jmvcCX/6sQ72uTKm0gkWgi1Zpd4ILfuHc77OjXJO/VQVeHsM7VeVUnzVZ0gi Ipt73bSf561ZoucCM45wSzdKknTXe8Q/S0OZ6GnFsJsdU6kJYi8m/CKUcmwlAU75pfbo 9LziUcGVN1tUcDCCw6mIanXiPCP8xKOgp2mB7+mN73g7jVys3O9Ky9N9N2o1Ocui7sib sPpiNfCLshKf3ru/ykNvTev76egTsJvEO/nypTdpcXAlotuL+Eo3he0awAxkM8BMSuX3 P7T8hKpwrRT+4FG0ofM8c8ekeQ+9Aq8ujYP58ApNkXbgCZTlF2HMV5zYIxrG/lXd6ike VIFA== X-Gm-Message-State: ALoCoQmBiIR6QXkzh0I6RnBXxEOCJ4pWer455V/LEcxQxZhvlyKSkb+CXLC3JCc2J1ISNTYcI7dN X-Received: by 10.194.7.199 with SMTP id l7mr1427893wja.2.1411598244861; Wed, 24 Sep 2014 15:37:24 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.2.65 with SMTP id 1ls207271las.63.gmail; Wed, 24 Sep 2014 15:37:22 -0700 (PDT) X-Received: by 10.152.10.203 with SMTP id k11mr9458208lab.30.1411598242675; Wed, 24 Sep 2014 15:37:22 -0700 (PDT) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id ir4si531680lac.116.2014.09.24.15.37.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Sep 2014 15:37:22 -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 1XWvBZ-0006y2-6M for std-proposals@isocpp.org; Thu, 25 Sep 2014 00:37:21 +0200 Original-Received: from cpe-67-240-43-113.nycap.res.rr.com ([67.240.43.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Sep 2014 00:37:21 +0200 Original-Received: from mw_triad by cpe-67-240-43-113.nycap.res.rr.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Sep 2014 00:37:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 61 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cpe-67-240-43-113.nycap.res.rr.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.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:13089 Archived-At: On 2014-09-24 18:08, Nevin Liber wrote: > On 24 September 2014 15:43, Matthew Woehlke wrote: >> On 2014-09-19 10:28, Tony V E wrote: >>> If/When you have both 'implicit' and 'explicit' keywords, I expect my >>> compiler to offer a warning whenever neither is used. >> >> OT, but I still very much want to see that happen :-). >> >> @Nevin, this relates to language issues where it's easy to forget an >> annotation that was desired resulting in undesired behavior of the code. > > *shrug* Unless you have a solution to the compatibility problem (has to > work with headers provided by vendors, has to work in environments where > every code change requires an expensive recertification of the software, > etc., etc.), it's a non-starter. In the short term, I would expect this to be via a warning. This means that the first problem is a non-issue (assuming you're using -isystem appropriately), and for the second problem, just turn it off (or don't use it; in the near term it would likely be opt-in rather than opt-out). In the long run, I really think (in general) there needs to be a process for phasing out (mis)features of the language. The usual way to do it is gradually; to start with, continue to allow the old way but provide a new alternative and encourage compiler authors to warn about the old way. Most of the transition happens at the vendor level... start turning the warning on by default, then make it an error by default. Eventually the cost to remove the old way is sufficiently low that you can do so. >> Providing an annotation for "yes, I really meant to do that" > > And when that becomes a pain point, tools will adjust so that people don't > have to think about it. Ideally by adding a -fexplicit-ctors option. > Do you sprinkle *every* function declaration in your code base with > noexcept specifications (true, false or conditional)? Why not, if, y'know, > explicit is always better? That's a poor example. Implicit ctors should be the *exception*, not the rule. An implicit ctor can be called when you don't expect, and as such, is more deserving of annotation to make it stand out than an explicit ctor. There is also a contradiction here; 'Foo(int)' is "magical" (implicit), while 'Foo(int, int)' is not, despite that the former has no annotation that tells the reader that it's special. I also think you're missing the point. I want the compiler to help me find bugs in my program. An implicit ctor that I didn't mean to be implicit is a bug. I want the compiler to be able to tell me 'hey, did you really mean this ctor to be implicit?' (which obviously implies having a way to say 'yes, really I did'). This way, if I *didn't* mean that, I am warned and have a chance to fix my code early, rather than it being silently wrong and coming back to bite me later in a way that's more difficult to track down. (Naturally, all of the above applies to conversion operators also...) -- 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/. .