220 13018 article Path: news.gmane.org!not-for-mail From: Nevin Liber Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Idea for new contextual keyword Date: Fri, 19 Sep 2014 12:18:46 -0500 Lines: 196 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: multipart/alternative; boundary=047d7bae47b09b036605036e4d8a X-Trace: ger.gmane.org 1411147176 30194 80.91.229.3 (19 Sep 2014 17:19:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Sep 2014 17:19:36 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBCE35H5S6IDBBH6L6GQAKGQEQJBZE5A@isocpp.org Fri Sep 19 19:19:29 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f71.google.com ([209.85.215.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XV1qC-000610-Sl for gclcip-std-proposals@m.gmane.org; Fri, 19 Sep 2014 19:19:28 +0200 Original-Received: by mail-la0-f71.google.com with SMTP id q1sf1815514lam.2 for ; Fri, 19 Sep 2014 10:19:28 -0700 (PDT) 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:from :date:message-id:subject: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=oJ5cOXv7SdjYa2fn68KBRyGJwL3cObcj636agURG1V8=; b=jWIjMYSLtK/T0vkDqHaocOO435EhEetu1U3+U+OiDtPqfayd0PQTFy9fhzpsiAdUpS 33xwGUM9P0Dt2qqNyH81zPzw6S9xRkwoiM8dwoh2v8xGrRg5tkB4JzjeZajqFoTGaiBx kU24CI5n/f6A0qOHc93PihgI/drE+3iP5DCkUkINNpKYtFx+OD5OWh7T46QTKLtWEswB T4qqC38FnHdMOedmN8cujp3fLh6EfdAcXN8bV2NyOfW+x/0N1UN20KAryhjYa/nDs9bu SxIsel5r1V0J/hkLfj7s2pLpUoGwWYVU1lWvBTTkccBdkfuOjBE785CKUye8wTyy/nrV N2TQ== X-Gm-Message-State: ALoCoQkhnia8nmJfRN30PfA4JW+b8edkhmkNCNN6mkBEuabvS4NJITw3khxmfrsLPUHXtekGoJyw X-Received: by 10.181.28.169 with SMTP id jp9mr2267699wid.6.1411147168683; Fri, 19 Sep 2014 10:19:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.13.209 with SMTP id j17ls141005wic.48.gmail; Fri, 19 Sep 2014 10:19:27 -0700 (PDT) X-Received: by 10.180.39.200 with SMTP id r8mr7325607wik.23.1411147167184; Fri, 19 Sep 2014 10:19:27 -0700 (PDT) Original-Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [2a00:1450:400c:c03::230]) by mx.google.com with ESMTPS id a9si2812935wjy.88.2014.09.19.10.19.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Sep 2014 10:19:26 -0700 (PDT) Received-SPF: pass (google.com: domain of nliber@gmail.com designates 2a00:1450:400c:c03::230 as permitted sender) client-ip=2a00:1450:400c:c03::230; Original-Received: by mail-we0-f176.google.com with SMTP id x48so112607wes.7 for ; Fri, 19 Sep 2014 10:19:26 -0700 (PDT) X-Received: by 10.194.191.135 with SMTP id gy7mr2404178wjc.39.1411147166841; Fri, 19 Sep 2014 10:19:26 -0700 (PDT) Original-Sender: nliber@gmail.com Original-Received: by 10.194.242.198 with HTTP; Fri, 19 Sep 2014 10:18:46 -0700 (PDT) In-Reply-To: X-Original-Sender: nevin@eviloverlord.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of nliber@gmail.com designates 2a00:1450:400c:c03::230 as permitted sender) smtp.mail=nliber@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:13018 Archived-At: --047d7bae47b09b036605036e4d8a Content-Type: text/plain; charset=UTF-8 On 19 September 2014 09:28, Tony V E wrote: > > > On Fri, Sep 19, 2014 at 10:21 AM, Nevin Liber > wrote: > >> On 19 September 2014 09:11, Tony V E wrote: >> >>> >>> >>> If a style guide is likely to say "typically use keyword 'foo'" then can >>> we please always also have the opposite keyword 'xfoo' for the explicit >>> non-use cases? >>> ie >>> style guides often say: >>> >>> - typically make constructors explicit >>> - typically make member functions const >>> - etc >>> >>> So when I see a constructor that is NOT explicit, I can't tell whether >>> that was intentional or a mistake. >>> >> >> Why don't you just require comments in your style guide for those cases? >> -- >> Nevin ":-)" Liber (847) 691-1404 >> >> -- >> > > Explicit is almost always better. > In your opinion. I take it you don't believe in using mechanisms like overloaded functions? Explicitness makes the code noisier. Adding syntax has a high cost. Providing yet another way to spell a comment (we already have at least 4: /* */, //, [[ ]], #if 0) doesn't meet my burden of being worth the cost. > Why don't we go back to C style function declarations without parameters? > C++ style function declarations are not comments; compilers must take action if they don't match. If you have any more straw man arguments to make, by all mean interject them into this conversation. > Relying on comments makes it harder for me or the compiler to produce > warnings. > Why? That's just a tooling issue, and not something covered by the standard. And you end up with a bunch of non-standard conventions. > Given that there is no universal C++ style guide endorsed by the C++ Committee, I don't see why that is a bad thing. > > If/When you have both 'implicit' and 'explicit' keywords, I expect my > compiler to offer a warning whenever neither is used. > Again, why? Not providing the implicit keyword is not incorrect. What precedence is there in the standard to require such behavior? If it isn't required, then it is just convention, and I don't see how adding it to the standard helps anything, other than people who want to use the "appeal to authority" argument by pointing to the standard as the blessed way of doing things. After all, if this is the behavior you want, one would expect the standard itself to have every such function annotated. We already have problems with compilers warning about "struct" vs. "class" differences. That seems like a lot of work just for a comment. -- Nevin ":-)" Liber (847) 691-1404 -- --- 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/. --047d7bae47b09b036605036e4d8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 19 September 2014 09:28, Tony V E <= ;tvaneerd@gmail.com= > wrote:


On Fri, Sep = 19, 2014 at 10:21 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
On 19 September 2014 09:11, Tony V E <tvanee= rd@gmail.com> wrote:


If a = style guide is likely to say "typically use keyword 'foo'"= ; then can we please always also have the opposite keyword 'xfoo' f= or the explicit non-use cases?
ie
style guides often say:<= br>
- typically make constructors explicit
- t= ypically make member functions const
- etc

= So when I see a constructor that is NOT explicit, I can't tell whether = that was intentional or a mistake.
=

Why don't you just require comments in your = style guide for those cases?
-- =C2=A0Nevin ":-)" Liber=C2=A0 <mailto:nevin@eviloverlord.com>=C2=A0 = (847) 691-1404

--

= Explicit is almost always better.

In your opinion.=C2=A0

I take it you don't = believe in using mechanisms like overloaded functions?

=
Explicitness makes the code noisier. =C2=A0Adding syntax has a high co= st. =C2=A0Providing yet another way to spell a comment (we already have at = least 4: =C2=A0/* */, //, [[ ]], #if 0) doesn't meet my burden of being= worth the cost.
=C2=A0
Why don't we go back to C style = function declarations without parameters?
=
C++ style function declarations are not comments; compilers = must take action if they don't match.

If you h= ave any more straw man arguments to make, by all mean interject them into t= his conversation.
=C2=A0
Relying on comments makes it harder= for me or the compiler to produce warnings.=C2=A0

Why? =C2=A0That's just a tooling issue, and not so= mething covered by the standard.

And you end up with a = bunch of non-standard conventions.

Given that there is no universal C++ style guide endorsed by the C+= + Committee, I don't see why that is a bad thing.=C2=A0

If/When you have both 'implicit' and = 9;explicit' keywords, I expect my compiler to offer a warning whenever = neither is used.

Again, why? = =C2=A0Not providing the implicit keyword is not incorrect. =C2=A0What prece= dence is there in the standard to require such behavior? =C2=A0If it isn= 9;t required, then it is just convention, and I don't see how adding it= to the standard helps anything, other than people who want to use the &quo= t;appeal to authority" argument by pointing to the standard as the ble= ssed way of doing things.

After all, if this is th= e behavior you want, one would expect the standard itself to have every suc= h function annotated. =C2=A0We already have problems with compilers warning= about "struct" vs. "class" differences. =C2=A0That see= ms like a lot of work just for a comment.
--
=C2=A0Nevin &qu= ot;:-)" Liber=C2=A0 <mailto:nevin@eviloverlord.com>=C2=A0 (847) 691-1404

--

---
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-proposa= ls+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>.
--047d7bae47b09b036605036e4d8a-- .