220 31928 <10c2c556-b6bb-4714-83bc-7b0ac8fd4143@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: This variable should not be named: an identifier (not) to remember Date: Sun, 2 Apr 2017 12:45:38 -0700 (PDT) Lines: 163 Approved: news@gmane.org Message-ID: <10c2c556-b6bb-4714-83bc-7b0ac8fd4143@isocpp.org> References: <985b9b2a-c734-45eb-95f4-db4dc0d309a1@isocpp.org> <1491170458.9U0G8TLsOk@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6711_57837783.1491162338604" X-Trace: blaine.gmane.org 1491162343 7234 195.159.176.226 (2 Apr 2017 19:45:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 2 Apr 2017 19:45:43 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBY5JQXDQKGQE5YJPLMQ@isocpp.org Sun Apr 02 21:45:38 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f197.google.com ([209.85.213.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1culRO-00012P-4p for gclcip-std-proposals@m.gmane.org; Sun, 02 Apr 2017 21:45:34 +0200 Original-Received: by mail-yb0-f197.google.com with SMTP id 74sf41986694ybf.1 for ; Sun, 02 Apr 2017 12:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=mV3NHbAK3PnAVf/5ntmK8NBMOuM1JwcAzlP1qlFk6b0=; b=mDjM9xlsqH6OHvMyKUJQy9oSxBdMQR+Kh55eO85YeFynllt8zEZUo8GSUIjJ4eSD19 LLSlrAUXkMOtcNgmcakWFzcrQx1W7X6TMsr3BtvTj0I2fItDpCM5y4bElwo3Dd/q72CE sIuEl9fS2Zoo2xxKPrLq5smAAWZ1XYHoL28fvMqJhYYvPsw9jaL6hIFAEgFLOf4BHg8w oIxmb23SvbjX7yeOxskaoPr+/bSwqJUgBvigYcpIJGS0tr1NvBaT2IHy1LIYpyWbWF47 aYG1gGS79OaECs8CKpnAXdoSLIY6Ie20uDwZrjf78QKryqj/e5NkL4vNAmX0mVSjEIQp yb9Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=mV3NHbAK3PnAVf/5ntmK8NBMOuM1JwcAzlP1qlFk6b0=; b=QkvY3Wna75crfJ3wGC6uGaJ1mo5Z3Dt+Pbt/BeYjF1b9ZfPaeuUkXV76PhDaCu+cJ0 tMefnP8+9Nx4LVDJHgyyw5ZiiNM4Li+gznVXNNPPE7lBsPWxbyUruFbOTAJfYmcHb7k8 Gsn7oGPofJhBC3A6gVG86RCLefbx9IXGBdN5mZLJYLqZVC0UXNlm0b8ZaKbuY/uRJqY0 IJpCAnO91Zy70PZ42RbgNTt4D8txQ8TGRvlbk1tmVSGLhb1k/VJUqNdiBRtoLEUUelVa 4tRW6OfGiDZSqW0sIrUa3bDcEwhRNFL8nADMrCv35tuuRFqJTKmU88+RpFq1gd8b2q+Z 8SYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=mV3NHbAK3PnAVf/5ntmK8NBMOuM1JwcAzlP1qlFk6b0=; b=iqwquoirGT7nUeL4UYNkhug7BMdkcFPvNr7wlzUZnmJ02Ry6M2An77gHsLxzbZ6tX6 p3smcpN+/ribHFF4aRhfhViJ4lKsOTKGzv2PjZtUIu/t2RYizWwirmHdO7jXAxFgLJYf VJqfDOKF4EKD5TLxyiIa2kYVh1tAyuV5eG4020xz044jiODpSRKZdzitYUTwP73obfW2 SBMP6bfTFMQg8cIAt8N/XByN09afZOoMLZDOGrma3c/2Wz4HmUtlwT1qjpNIeO5DP/PO 0RMEZQt6n7fV7GJOgXMUTNPJ6hFPjPHwbew4208cnmSlXnKMAwFd9wpVhsGM214CZlyk 13Dw== X-Gm-Message-State: AFeK/H2wKw94Xw3/WWDhcrDqxjOHameOiuBy6gayzNyXRPaDn0906hQ5/jQDYzZGmNQOlA== X-Received: by 10.129.107.134 with SMTP id g128mr6256308ywc.139.1491162339943; Sun, 02 Apr 2017 12:45:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.29.8 with SMTP id m8ls1806673otm.34.gmail; Sun, 02 Apr 2017 12:45:39 -0700 (PDT) X-Received: by 10.157.18.211 with SMTP id g77mr62585otg.8.1491162339087; Sun, 02 Apr 2017 12:45:39 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:31928 Archived-At: ------=_Part_6711_57837783.1491162338604 Content-Type: multipart/alternative; boundary="----=_Part_6712_493131040.1491162338604" ------=_Part_6712_493131040.1491162338604 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, April 2, 2017 at 3:28:54 PM UTC-4, Richard Smith wrote: > > On 2 April 2017 at 11:03, Thiago Macieira > wrote: > >> On s=C3=A1bado, 1 de abril de 2017 21:19:37 PDT Richard Smith wrote: >> > Have you considered that possibility? It would give a better name (_= =20 >> rather >> > than __) and avoid "breaking" existing code that uses __. >> >> _ is not reserved to the compiler and is VERY often #defined to gettext. >> > > Only as a function-like macro. > > Let's use __. > > > Let's use the thing that works best for C++, sure. I am not (yet)=20 > convinced that's __. > Well, let's look at the options. You can't use nothing; that would create parsing ambiguities. So you have= =20 to put something there: either an identifier or something that is not an=20 identifier. If it is not an identifier, then it must be a keyword (new or old) or some= =20 form of punctuation. Adding a new keyword for something like this is rather= =20 silly. And I don't know of an old keyword that would make for a good=20 placeholder. You could use `[]` as I once suggested, piggybacking off of structured=20 binding rules. But most other punctuation would be confusing or otherwise= =20 unexpected in a variable declaration. If it is an identifier, then it must be a *reserved* identifier, to=20 minimize code breakage when we change its meaning. The shortest reserved=20 identifier is `_`, which is currently reserved for use by the=20 implementation, but only for names in the global namespace. Which means=20 that right now, this is 100% legal: namespace foo { constexpr int _ =3D 20; } So changing the meaning of that code is a non-starter. The second shortest reserved identifiers are of the form `_*`, where `*` is= =20 an uppercase letter or `_`. These are reserved by the implementation for *a= ny=20 use*. And implementations are more easily changed than user code. So from my perspective, `__` is the most viable identifier. --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/10c2c556-b6bb-4714-83bc-7b0ac8fd4143%40isocpp.or= g. ------=_Part_6712_493131040.1491162338604 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sunday, April 2, 2017 at 3:28:54 PM UTC-4, Richard Smit= h wrote:
=
On 2 April 2017 at 11:03, Thiago Macieira <thi...@macieira.org> wrote:
On s=C3=A1bado, 1 de abril de 2017 21:19:37 PDT Richard= Smith wrote:
> Have you considered that possibility? It would give a better name (_ r= ather
> than __) and avoid "breaking" existing code that uses __.
_ is not reserved to the compiler and is VERY often #defined to gett= ext.

Only as a function-like macro.

Let's use __.

Let's use the thing t= hat works best for C++, sure. I am not (yet) convinced that's __.
=

Well, let's look at the options= ..

You can't use nothing; that would create parsing ambiguities. = So you have to put something there: either an identifier or something that = is not an identifier.

If it is not an identifier, then it must be a = keyword (new or old) or some form of punctuation. Adding a new keyword for = something like this is rather silly. And I don't know of an old keyword= that would make for a good placeholder.

You could use `[]` as I onc= e suggested, piggybacking off of structured binding rules. But most other p= unctuation would be confusing or otherwise unexpected in a variable declara= tion.

If it is an identifier, then it must be a reserved iden= tifier, to minimize code breakage when we change its meaning. The shortest = reserved identifier is `_`, which is currently reserved for use by the impl= ementation, but only for names in the global namespace. Which means that ri= ght now, this is 100% legal:

namespace foo
{
=C2=A0 constexpr int _ =3D 20;
}

So changing = the meaning of that code is a non-starter.

The second shortest reser= ved identifiers are of the form `_*`, where `*` is an uppercase letter or `= _`. These are reserved by the implementation for any use. And implem= entations are more easily changed than user code.

So from my perspec= tive, `__` is the most viable identifier.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/10c2c556-b6bb-4714-83bc-7b0ac8fd4143= %40isocpp.org.
------=_Part_6712_493131040.1491162338604-- ------=_Part_6711_57837783.1491162338604-- .