220 9320 article Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: add "implicit" keyword? Date: Wed, 12 Feb 2014 09:47:46 -0500 Lines: 178 Approved: news@gmane.org Message-ID: References: <1908685.x2fBXFHVm8@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1139b03ef695ad04f236a7ef X-Trace: ger.gmane.org 1392216461 20239 80.91.229.3 (12 Feb 2014 14:47:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 12 Feb 2014 14:47:41 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDIIVO6GQULBBE4T52LQKGQED5LNZUI@isocpp.org Wed Feb 12 15:47:49 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WDb6K-00078O-SQ for gclcip-std-proposals@m.gmane.org; Wed, 12 Feb 2014 15:47:49 +0100 Original-Received: by mail-ie0-f199.google.com with SMTP id lx4sf11766971iec.6 for ; Wed, 12 Feb 2014 06:47:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from: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=nVx7a17pnH4CaMq7/syOdvZFHlSI0e5Y1fgk8nrtHRI=; b=UDNYoSYw0mcvimn5vbvzr8MwZOzpm1qQciH3XA8RjSH+XO6yztfiCii6cqdm7+ZBJO bidFvsqWAf3DDN3TpJMHcYPddApcCgRs57Trt0m4y1aVsQL6VblbD8gur3sCphiPtb3A 0SppSDdw5EXOZeYbpSh8l9H4sX7WyBYuf5UIkorh9e8golmvkQ707dlmW2gUUqRa8s8W rSxO+UrTfKaUPL8e2j7FSCQcjhKWy069hA3zpoHg3ZuCiO4jATSLZz2xdSawVQNBG/HD BGH9XU2/zqrEWPfh6YLZYR8SQQkghK3idZgmJ6Og0Ujr8SaT/67Lm9jD/cyemRyIRUE/ qCuw== X-Gm-Message-State: ALoCoQlyzSHuHSZKTK7wPTuUEpbczO7IwwbhlHByNsVPNdQj6nE8oTRCrp0JdB1vadJBb+EqPrQm X-Received: by 10.50.12.68 with SMTP id w4mr1729892igb.0.1392216467981; Wed, 12 Feb 2014 06:47:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.25.198 with SMTP id 64ls2946446qgt.31.gmail; Wed, 12 Feb 2014 06:47:47 -0800 (PST) X-Received: by 10.140.102.69 with SMTP id v63mr64725025qge.5.1392216467155; Wed, 12 Feb 2014 06:47:47 -0800 (PST) Original-Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [2607:f8b0:400d:c01::235]) by mx.google.com with ESMTPS id j77si15371309qge.194.2014.02.12.06.47.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 06:47:47 -0800 (PST) Received-SPF: pass (google.com: domain of dribeas@gmail.com designates 2607:f8b0:400d:c01::235 as permitted sender) client-ip=2607:f8b0:400d:c01::235; Original-Received: by mail-qc0-f181.google.com with SMTP id e9so15573964qcy.12 for ; Wed, 12 Feb 2014 06:47:47 -0800 (PST) X-Received: by 10.140.109.72 with SMTP id k66mr64515422qgf.20.1392216466952; Wed, 12 Feb 2014 06:47:46 -0800 (PST) Original-Sender: dribeas@gmail.com Original-Received: by 10.140.24.37 with HTTP; Wed, 12 Feb 2014 06:47:46 -0800 (PST) In-Reply-To: <1908685.x2fBXFHVm8@tjmaciei-mobl4> X-Original-Sender: dibeas@ieee.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of dribeas@gmail.com designates 2607:f8b0:400d:c01::235 as permitted sender) smtp.mail=dribeas@gmail.com; dkim=pass header.i=@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:9320 Archived-At: --001a1139b03ef695ad04f236a7ef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On a completely orthogonal direction, why not use attributes to do this, and let compiler writers handle it. I imagine you could do: struct X { [[implicit]] X(int); }; struct Y { Y(int); }; With a compiler flag to diagnose the lack of the attribute, so the above would compile fine in one mode, or provide a diagnostic if -Wdefault-implicit (error with -Edefault-implicit) in Y's constructor. There is nothing that blocks a compiler from doing this already in C++11, but I can see that the specific attribute to use could be standarized. This has the advantage of not implying changes to the standard (other than the possible standarization of the attribute spelling), it does not introduce keywords or contextual keywords or anything that has to be special cased in the compiler since attributes need to be supported already and it is backwards compatible (C++11 compilers not supporting this feature would just ignore the attribute). David On Tue, Feb 11, 2014 at 1:11 PM, Thiago Macieira wrote= : > Em seg 10 fev 2014, =E0s 11:30:32, Matthew Woehlke escreveu: > > Objective: > > ---------- > > Create a new keyword "implicit", having the meaning 'not "explicit"'. > > That is, this keyword would annotate that a constructor or conversion > > operator is allowed to be called in a manner that would be denied by > > 'explicit'. > [snip] > > I think it's a good idea and I support. > > For example, in KDE we have a policy: every one-argument constructor must > either have the "explicit" keyword or must have "implicit" in a comment o= n > the > same line[1]. Then we have an after-the-fact source code checker that > verifies > everything and produces warnings. > > A keyword woud allow us to dump that part of the script and just enable a > compiler warning, or even a -Werror. > > [1] the rule wasn't updated to deal with C++11 initialisation lists. > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > > -- > > --- > 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/. > --=20 ---=20 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 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-proposa= ls/. --001a1139b03ef695ad04f236a7ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On a completely orthogonal direction, why not use attribut= es to do this, and let compiler writers handle it. I imagine you could do:<= br>
struct X {
=A0 =A0[[implicit]] X(int);
};
struct Y {
= =A0 =A0Y(int);
};

With a compiler flag to diagnose the lack of the attribute, so th= e above would compile fine in one mode, or provide a diagnostic if -Wdefaul= t-implicit (error with -Edefault-implicit) in Y's constructor.

There is nothing that blocks a compiler from doing this already in C++11, b= ut I can see that the specific attribute to use could be standarized.
This has the advantage of not implying changes to the standard (other tha= n the possible standarization of the attribute spelling), it does not intro= duce keywords or contextual keywords or anything that has to be special cas= ed in the compiler since attributes need to be supported already and it is = backwards compatible (C++11 compilers not supporting this feature would jus= t ignore the attribute).=A0

=A0 =A0 David


On Tue, Feb 11, 2014 at 1:11 PM, Thiago Macieira <thiag= o@macieira.org> wrote:
Em seg 10 fev 2014, =E0s 11:30:32, Matthew W= oehlke escreveu:
> Objective:
> ----------
> Create a new keyword "implicit", having the meaning 'not= "explicit"'.
> That is, this keyword would annotate that a constructor or conversion<= br> > operator is allowed to be called in a manner that would be denied by > 'explicit'.
[snip]

I think it's a good idea and I support.

For example, in KDE we have a policy: every one-argument constructor must either have the "explicit" keyword or must have "implicit&qu= ot; in a comment on the
same line[1]. Then we have an after-the-fact source code checker that verif= ies
everything and produces warnings.

A keyword woud allow us to dump that part of the script and just enable a compiler warning, or even a -Werror.

[1] the rule wasn't updated to deal with C++11 initialisation lists.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
=A0 =A0Software Architect - Intel Open Source Technology Center
=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:
=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358

--

---
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-propo= sals+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/gro= up/std-proposals/.

--
 
---
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>.
--001a1139b03ef695ad04f236a7ef-- .