220 31932 <0E248E15-9ECD-4E5C-B38C-55417E91C276@gmail.com> article Path: news.gmane.org!.POSTED!not-for-mail From: Alberto Barbati 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 23:11:13 +0200 Lines: 148 Approved: news@gmane.org Message-ID: <0E248E15-9ECD-4E5C-B38C-55417E91C276@gmail.com> 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 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_6970A8FE-8A60-42EE-B1FE-085CB1337529" X-Trace: blaine.gmane.org 1491167484 21986 195.159.176.226 (2 Apr 2017 21:11:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 2 Apr 2017 21:11:24 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCPY5DV6RIMBB5ORQXDQKGQEUC2IL7I@isocpp.org Sun Apr 02 23:11:19 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr0-f199.google.com ([209.85.128.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cummG-0004Vk-A5 for gclcip-std-proposals@m.gmane.org; Sun, 02 Apr 2017 23:11:12 +0200 Original-Received: by mail-wr0-f199.google.com with SMTP id p52sf21606034wrc.8 for ; Sun, 02 Apr 2017 14:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:references:to:in-reply-to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=cYTaC+AsXetqxv0I6V2PCq3bqchDTRBFg2Kk8QDRInw=; b=dpPoWqJnFCmzTp/wpFO23iZ0QHFzXnwfNrCzY7Ja01Zc9+xAbIurim+VsRICUfYWjG C8jNfOz7ThiCNCepyBsodRG1R1Xhb1dboFVOpMnqwqVad8ZZ7HDWu2DMksOrSksmXh9O igEtWK2rsWMmYU/REJ3hyiP5OOafMkwxxWIpabEvC9ql3MLg3U/rzVJ8id3Kgz9ez80v tv5TgPUIXwQUEUYC4eDXECJqotfMiFwlHYWfdzCoMITiHLtYcanLj4l6fQdw0p6NiuvM UPLLex5T5JlS3/n+Ef7WkHoSq3akM2jtX4K3x31TxMAKurh7BYXZkbvqRp9CQxKj5Ix7 6PnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=cYTaC+AsXetqxv0I6V2PCq3bqchDTRBFg2Kk8QDRInw=; b=l8lqtZUXBbCyrt6/toIsvzLmeaj1zX8dYz539OyDezP55pXNm+8BhPpACetPAeTDLj FFecLxTv2woQ7z17vfGYtfV6DEp/5P6jCz5vdz3LJc7sQvrIn7ddmuYdfBWWrU6SBGtn 8WMewA/SvIgeF2FCDDHT+mIL3xwwnv+CsrA6VyBlqEb57PFC4JzaGkF+syBuJBm1GHkw V6Whvz7gT+b1tS2kSElb3sDXFEAPRh0fFYGW9hDib+plO5IBG9jKhKBKf0A4TYjdfora Z8UYlsuCJlaV9NEEhowrJWN4iCXHiOIYshKr6+5d/FWD8H/avOuxR0ODlKTkR7ANwYcI Wsyg== X-Gm-Message-State: AFeK/H3imgIwezLOEd6sJefGz0iXdWzCBoPaAlahlCqCrvY6QVPhzg43 8Bn/QWIGWPfLOA== X-Received: by 10.28.179.8 with SMTP id c8mr240492wmf.22.1491167478375; Sun, 02 Apr 2017 14:11:18 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.63.87 with SMTP id m84ls573028wma.4.gmail; Sun, 02 Apr 2017 14:11:17 -0700 (PDT) X-Received: by 10.223.129.199 with SMTP id 65mr12284786wra.118.1491167477070; Sun, 02 Apr 2017 14:11:17 -0700 (PDT) Original-Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com. [2a00:1450:400c:c0c::229]) by mx.google.com with ESMTPS id k45si17201255wrc.87.2017.04.02.14.11.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Apr 2017 14:11:17 -0700 (PDT) Received-SPF: pass (google.com: domain of albertobarbati@gmail.com designates 2a00:1450:400c:c0c::229 as permitted sender) client-ip=2a00:1450:400c:c0c::229; Original-Received: by mail-wr0-x229.google.com with SMTP id w11so142808226wrc.3 for ; Sun, 02 Apr 2017 14:11:17 -0700 (PDT) X-Received: by 10.223.160.239 with SMTP id n44mr12944650wrn.198.1491167476499; Sun, 02 Apr 2017 14:11:16 -0700 (PDT) Original-Received: from yudhisthira.fritz.box ([151.20.198.68]) by smtp.gmail.com with ESMTPSA id 191sm11624019wmv.25.2017.04.02.14.11.15 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 02 Apr 2017 14:11:15 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3124) X-Original-Sender: AlbertoBarbati@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of albertobarbati@gmail.com designates 2a00:1450:400c:c0c::229 as permitted sender) smtp.mailfrom=albertobarbati@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:31932 Archived-At: --Apple-Mail=_6970A8FE-8A60-42EE-B1FE-085CB1337529 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > Il giorno 02 apr 2017, alle ore 22:10, Richard Smith ha scritto: >=20 > On 2 April 2017 at 12:56, Alberto Barbati > wrote: > Il giorno 02 apr 2017, alle ore 20:03, Thiago Macieira > ha scritto: >=20 > >> 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 gettext= .. >=20 > Thank you Richard for your suggestion which is very interesting, since it= provides good insights about a possible wording. As for the name, I believ= e Thiago and Magnus raised valid concerns, though. It's true that the we mi= ght choose _ without breaking existing code. However defining _ as a macro = is currently valid and apparently widely used. I believe we therefore have = only two choices: either we make such uses undefined behavior (upsetting a = lot of people) or we choose wording to avoid that (making the feature essen= tially unusable for users of all libraries like gettext). None of the two a= pproaches seems very good. Is there a third option? >=20 > As noted, gettext defines _ as a function-like macro, so there seems to b= e no technical problem for users of gettext (although some might consider o= verloading the meaning of _ in this way to be a readability problem). I guess the proposal might use an assessment of the usage of _ as a macro n= ame. However, I am a bit worried about this: unique_lock _ (mutex1); // ok, _ is an identifier unique_lock _(mutex2); // ops! may not compile if I #include gettext >=20 > __ seems somewhat safer and less controversial. >=20 > 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 consider to be= poorly chosen, so I don't think it's clear which will be less controversia= l. Duly noted. By the way, I personally don=E2=80=99t think __ is much worse t= han _. This seems very subjective to me. Alberto --=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/0E248E15-9ECD-4E5C-B38C-55417E91C276%40gmail.com= .. --Apple-Mail=_6970A8FE-8A60-42EE-B1FE-085CB1337529 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
Il giorno 02 apr 201= 7, alle ore 22:10, Richard Smith <richard@metafoo.co.uk> ha scritto:

On 2 April 2017 at 12:56, = Alberto Barbati <albertobarbati@gmail.com= > wrote:
Il giorno 02 apr 2017, alle ore 20:03, Thiago Macieira <thiago@macieira.o= rg> 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 m= acro is currently valid and apparently widely used. I believe we therefore = have only two choices: either we make such uses undefined behavior (upsetti= ng a lot of people) or we choose wording to avoid that (making the feature = essentially unusable for users of all libraries like gettext). None of the = two approaches seems very good. Is there a third option?

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

I guess the proposal m= ight use an assessment of the usage of _ as a macro name.

However, I am a bit worried about this:

  unique_lock _ (mutex1); // ok, _ is an identifie= r
  unique_lock _(mutex2); // ops! may not compile if I #inc= lude gettext


__ seems somewhat safer and less controversial.

I would expect you'll find controvers= y if you pick a worse name in order to avoid collision with a macro name th= at some would already consider to be poorly chosen, so I don't think it's c= lear which will be less controversial.

Duly noted. By the way, I personally don=E2= =80=99t think __ is much worse than _. This seems very subjective to me.

Alberto

--
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.c= om/a/isocpp.org/d/msgid/std-proposals/0E248E15-9ECD-4E5C-B38C-55417E91C276%= 40gmail.com.
--Apple-Mail=_6970A8FE-8A60-42EE-B1FE-085CB1337529-- .