220 31934 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 15:50:50 -0700 (PDT) Lines: 188 Approved: news@gmane.org Message-ID: References: <985b9b2a-c734-45eb-95f4-db4dc0d309a1@isocpp.org> <1491170458.9U0G8TLsOk@tjmaciei-mobl1> <170CB823-B63F-4910-A227-95C23314ADAD@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5936_1928593301.1491173450884" X-Trace: blaine.gmane.org 1491173453 7056 195.159.176.226 (2 Apr 2017 22:50:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 2 Apr 2017 22:50:53 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBS4AQ3DQKGQED7WFIJA@isocpp.org Mon Apr 03 00:50:49 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cuoKc-0000yR-Hf for gclcip-std-proposals@m.gmane.org; Mon, 03 Apr 2017 00:50:46 +0200 Original-Received: by mail-oi0-f72.google.com with SMTP id r203sf91413336oib.15 for ; Sun, 02 Apr 2017 15:50:52 -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=084ZkEWyXdwBB8bpuiQaPW6bbIOxz1t0mqOt0+3F0A0=; b=M1H0002MJzUJq9AdEmcY9VH2wBSuqG58WECoacSzB7wKpX8aANrsf/SA/OXTPKWJ7T YQMv3okcW/0MakhwGgrr9GIuVo4oB/29XCijmNCvnI8URlJBxicbuCo4xtvoO+CXoYNq Y4IVPzVHfKqvjMfqGziN7FCylZahZ1kAwchS2n5OCUuYdXqE+DsuzASGWUPZ1hJSgwy3 o2nEK/5X5d7mCvr+8upJ1GzT6M6f+MIPAeReaH7mL5AA6XEgbt6GGHvMPzZvXjpWmCNU 0wmqmPzBngRxCZMNG6tOO+qzvL/0x2585ztLgSprDakrtrqJRc5eq4FzWgBowj8oT7Uy pPsg== 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=084ZkEWyXdwBB8bpuiQaPW6bbIOxz1t0mqOt0+3F0A0=; b=YjdUJLF+O/3tCsUfJh+NG/NhKVu0TcL1jJYZ4rzhENVKSELRoolqlbvvVIymVbWbgH FuhczpzsdlYCtqJO7zR1y2WW1kuOR3HyGwJ4itZIFpT9gFcL8251bUlLt3dvkVObMWe9 fakoy0eWqxtoyK8eezIvRnvEWgX5tnm1RBOBr8SHNsYs6MYG5WB5Utz3YsfVvji+s9dV 8B2Rlahs7bohI4mH9WNIRv4zP0tkmc4H0SzU3hzHZi1/h1VvXedfkH+8i8OYA3dGCxJ9 wizPqTsXzW1o7CYhpX0pSO7EwhjaJZpoeXzHYOhjL1ZwmXPUzPKxj4fYT3Z+W7SvuLNB KBVA== 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=084ZkEWyXdwBB8bpuiQaPW6bbIOxz1t0mqOt0+3F0A0=; b=jzpl1WP9+XrYTvynaZJZQq+dT0rSejLMjs9Qt/7b/vrh+maBF1mBe0NCx2HTlpFW2Y wqAplAxSrDfd/AdnZGRv+5ooqnvPo9eNz2OvxzcfGZbCRHfDgQu1vpu+dLadg2H5aw6J PCuEvFHDET58lXGGNx+3hRm+0wxKmEGYROcv3ghgVLFHyuMEM7lXFJaQT2hogoBkpVbi 3oijzN6ZK6hQhBhcH/BsovHQSA+tDHBtf7DK+yorcGmNmu6z2poNePNGNIXjYOeRMHms YKX300txQ9MS2UQ0eEA5moDRN0/pSq0p61ydzaPclr0dmvCHf4+QtXqZS4SZ18ULaW// y98Q== X-Gm-Message-State: AFeK/H26zbwL9T3GP5hdbWs1Zvh0miWUoIqNduFDXBWkzL05vxa93PADJ0YzkVUtQl/nOA== X-Received: by 10.157.19.11 with SMTP id f11mr5403367ote.48.1491173452122; Sun, 02 Apr 2017 15:50:52 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.47.171 with SMTP id r40ls6501457otb.0.gmail; Sun, 02 Apr 2017 15:50:51 -0700 (PDT) X-Received: by 10.157.46.203 with SMTP id w69mr637590ota.5.1491173451420; Sun, 02 Apr 2017 15:50:51 -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:31934 Archived-At: ------=_Part_5936_1928593301.1491173450884 Content-Type: multipart/alternative; boundary="----=_Part_5937_48829538.1491173450884" ------=_Part_5937_48829538.1491173450884 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, April 2, 2017 at 4:10:38 PM UTC-4, Richard Smith wrote: > > On 2 April 2017 at 12:56, Alberto Barbati > wrote: > >> Il giorno 02 apr 2017, alle ore 20:03, Thiago Macieira < >> thi...@macieira.org > ha scritto: >> >> >> 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 gettex= t. >> >> Thank you Richard for your suggestion which is very interesting, since i= t=20 >> provides good insights about a possible wording. As for the name, I beli= eve=20 >> Thiago and Magnus raised valid concerns, though. It's true that the we= =20 >> might choose _ without breaking existing code. However defining _ as a= =20 >> macro is currently valid and apparently widely used. I believe we theref= ore=20 >> have only two choices: either we make such uses undefined behavior=20 >> (upsetting a lot of people) or we choose wording to avoid that (making t= he=20 >> feature essentially unusable for users of all libraries like gettext). N= one=20 >> of the two approaches seems very good. Is there a third option? >> > > As noted, gettext defines _ as a function-like macro, so there seems to b= e=20 > no technical problem for users of gettext (although some might consider= =20 > overloading the meaning of _ in this way to be a readability problem). > But we can't do that. As previously mentioned, this does break valid code: namespace Name { int _ =3D 5; }; `_` is only reserved for implementation use in the global namespace. That= =20 name is not in a global namespace, so it's perfectly fine for users to use= =20 it. Using it for this feature would change this code, such that the variable is= =20 no longer accessible. __ seems somewhat safer and less controversial. > > > I would expect you'll find controversy if you pick a worse name in order= =20 > to avoid collision with a macro name that some would already consider to = be=20 > poorly chosen, so I don't think it's clear which will be less controversi= al. > I've yet to see evidence that `__` is in any technical way worse than `_`. --=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/cc7b0dfd-38c5-4bfc-b0d4-7a3d2fe81ef6%40isocpp.or= g. ------=_Part_5937_48829538.1491173450884 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sunday, April 2, 2017 at 4:10:38 PM UTC-4, Rich= ard Smith wrote:
On 2 April 2017 at 12:56, Alberto Barbat= i <alberto...@gmail.com> wrote:
Il giorno 02 apr 2017, alle ore 20:03, Thiago Ma= cieira <thi...@macieira.org> ha scritto:

>> On s=C3=A1bado, 1 de abril de 2017 21:19:37 PDT Richard Smith wrot= e:
>> Have you considered that possibility? It would give a better name = (_ rather
>> than __) and avoid "breaking" existing code that uses __= ..
>
> _ is not reserved to the compiler and is VERY often #defined to gettex= t.

Thank you Richard for your suggestion which is very interesting, sin= ce it provides good insights about a possible wording. As for the name, I b= elieve Thiago and Magnus raised valid concerns, though. It's true that = the we might choose _ without breaking existing code. However defining _ as= a macro is currently valid and apparently widely used. I believe we theref= ore have only two choices: either we make such uses undefined behavior (ups= etting a lot of people) or we choose wording to avoid that (making the feat= ure essentially unusable for users of all libraries like gettext). None of = the two approaches seems very good. Is there a third option?

As noted, gettext defines _ as a function-like macro,= so there seems to be no technical problem for users of gettext (although s= ome might consider overloading the meaning of _ in this way to be a readabi= lity problem).

But we can'= t do that. As previously mentioned, this does break valid code:

namespace Name
{
=C2=A0 int _ =3D 5;
};

`_` is only reserved for implementation use in the global namespace. = That name is not in a global namespace, so it's perfectly fine for user= s to use it.

Using it for this feature would change this code, such = that the variable is no longer accessible.

__ seems somewhat safer and less controversial.

=
I would expect you'll find controversy if you pick a worse name in= order to avoid collision with a macro name that some would already conside= r to be poorly chosen, so I don't think it's clear which will be le= ss controversial.

I've yet= to see evidence that `__` is in any technical way worse than `_`.

--
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/cc7b0dfd-38c5-4bfc-b0d4-7a3d2fe81ef6= %40isocpp.org.
------=_Part_5937_48829538.1491173450884-- ------=_Part_5936_1928593301.1491173450884-- .