220 31831 <94be2101-d81a-4ea2-bc78-cddc33cad37e@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: Tue, 28 Mar 2017 10:31:27 -0700 (PDT) Lines: 151 Approved: news@gmane.org Message-ID: <94be2101-d81a-4ea2-bc78-cddc33cad37e@isocpp.org> References: <985b9b2a-c734-45eb-95f4-db4dc0d309a1@isocpp.org> <2752007.h0gmCLmLCc@tjmaciei-mobl1> <6096248.pKJ4QPQkKS@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_11498_123145833.1490722287676" X-Trace: blaine.gmane.org 1490722297 2166 195.159.176.226 (28 Mar 2017 17:31:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Mar 2017 17:31:37 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB4F35LDAKGQEGVOHLYY@isocpp.org Tue Mar 28 19:31:33 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f200.google.com ([209.85.216.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csuxm-0007jJ-TP for gclcip-std-proposals@m.gmane.org; Tue, 28 Mar 2017 19:31:23 +0200 Original-Received: by mail-qt0-f200.google.com with SMTP id h56sf59192384qtc.10 for ; Tue, 28 Mar 2017 10:31:29 -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=CvUMjM9aHaNVv8AknD3F+3Jx07BZPiWmq/rOA/3LStE=; b=uAGWf0kJFYMO5r8E0Ee2+tyWOA4qJuyTp/Nr68XHEumSCiDWtHep4esFkFc9b8GvJj pbLybmbjp6gmW+3gVvFMw4/QAjGdmzi8hIn6I6hlmq/uHOWtejBYTSMBDlKJv7/LIdih ecLCDmjgchfnBGRwc1iQFUAHhGY8CvUwVvLYoOQGfa74uVxl8Ul1/barquxz5+lreUk1 3Bd8DO/pJynkkpJCaM+aL1r9pOlrimWSO4bYa5wzrq7wnzln2DEqzpEtJTwY+CWzutb4 Zbgj6iNnucRRjZ6Ikiy4BrbOcUof+3D1gc7DmACCq7ck23rycsPnAQVlF8BdJG46xaiP Znig== 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=CvUMjM9aHaNVv8AknD3F+3Jx07BZPiWmq/rOA/3LStE=; b=ACSUyIwLgLm1xVMobWjcFZZ0/Iro0y6+QRItq5an+6TyxDtlLpzgtDajg3mDMpz6p+ N6iHaPeAr0gl4a6riG6K1dHI+lM7/8Tqfvi+7lPmyNyiasLf7yS4p4mrUevREOQZxMxn 25f+uE6K0DkmfFZfr2JXFDWm1rsORxabcQvj6/Gg+9L8xGDtfoiAmjD94Q/EjPYnSKRc +xD4wvl7FpZa1nL0H3HKwTeYn+2vppKZgj8H6q6aoU2fLDGRvDK1RwXKbb0/+Q3izPh5 oF154BxpQh5hF8YkizAHxlDWe301nd4ckaOVyOdjF/nCveC3UgzUGmVqSclbH0yeqGs0 2wAA== 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=CvUMjM9aHaNVv8AknD3F+3Jx07BZPiWmq/rOA/3LStE=; b=o4URZa2Qfev5fRudKlgYEEjHv5dmp/IAZ5Nd6fiq1DxxZg/7AobeJZzytTP94yuxHr w8S3yIY1YHfaPq5YXnQL6cZphyRdMjdN7RHvrhcULDxh5617P0CHSBAWsl+E53PN/n8H XFVJTc2cdtc6foZ4vlfsKBr78Y6LYOY9E8dXn3VW6km7Oq+HcQ+d7Iz0+0NpVLIUhgfM 0E8oOcKAbQv9n1Xt/q3HzxOjmtWytbdKk1FhJExdd42i9kP+vY8Xlmh1S9wgIglvrRMl JB5rKaW8mbz+Y0ViuEQN8HGWsMfkyBDV4V5nTk0jKvjFIFQ1lKtoOodkPOFMvmrHXr1r M6XA== X-Gm-Message-State: AFeK/H29NZuyrwmDpZXo+/pRYkiyMfq1dS2Ee9GxVs3bP6NKjt3zake2YXnCk3Lpem4iyQ== X-Received: by 10.200.55.241 with SMTP id e46mr9204249qtc.22.1490722288777; Tue, 28 Mar 2017 10:31:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.62.1 with SMTP id a1ls677708otd.37.gmail; Tue, 28 Mar 2017 10:31:28 -0700 (PDT) X-Received: by 10.157.11.150 with SMTP id 22mr1025022oth.18.1490722288001; Tue, 28 Mar 2017 10:31:28 -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:31831 Archived-At: ------=_Part_11498_123145833.1490722287676 Content-Type: multipart/alternative; boundary="----=_Part_11499_695470842.1490722287676" ------=_Part_11499_695470842.1490722287676 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, March 28, 2017 at 1:21:46 PM UTC-4, Matt Calabrese wrote: > > On Tue, Mar 28, 2017 at 1:39 AM, Thiago Macieira > wrote: > >> On segunda-feira, 27 de mar=C3=A7o de 2017 15:16:58 PDT 'Jeffrey Yasskin= ' via=20 >> ISO C >> ++ Standard - Future Proposals wrote: >> > > Just remember that there are already existing codebases using __ as >> > > identifier >> > > or macro names. >> > >> > They're not allowed. "_" is ok outside of the global namespace, but=20 >> "__" is >> > reserved by [lex.name]. >> >> I know it is. >> >> And yet it's in use. >> https://github.com/v8/v8/blob/master/src/x64/codegen-x64.cc#L33 > > > If we are afraid to break people who use explicitly reserved identifiers,= =20 > then I think we'd be making a huge mistake. I agree that we should always= =20 > minimize breaking people when it makes sense and I know that people draw= =20 > the line at different places, but we should at least be able to make use = of=20 > an identifier that has been reserved since the initial standard. > I have to agree with that. This is literally the *whole point* of reserving= =20 identifiers: so that we can use them later. It's not like adding a keyword,= =20 where we need to study the impact of making a change so as to minimize=20 breakage. If someone was using a reserved identifier (outside of a standard library= =20 implementation), their code is wrong. We told them to stay out of this=20 area, and they didn't. Their code breaking is not our fault, nor is it on= =20 us to stay out of their way. Now, one thing that's important in this regard is that we should do a study= =20 on the impact of this change on standard library implementations. Since we= =20 would obviously be taking away one of their identifiers. --=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/94be2101-d81a-4ea2-bc78-cddc33cad37e%40isocpp.or= g. ------=_Part_11499_695470842.1490722287676 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, March 28, 2017 at 1:21:46 PM UTC-4, Matt Calab= rese wrote:
On Tue, Mar 28, 2017 at 1:39 AM, Thiago Macie= ira <thi...@macieira.org> wrote:
On segunda-feira, 27 de mar=C3=A7o de 2017 15:16:58= PDT 'Jeffrey Yasskin' via ISO C
++ Standard - Future Proposals wrote:
> > Just remember that there are already existing codebases using __ = as
> > identifier
> > or macro names.
>
> They're not allowed. "_" is ok outside of the global nam= espace, but "__" is
> reserved by [lex.name].

I know it is.

And yet it's in use.
https://github.co= m/v8/v8/blob/master/src/x64/codegen-x64.cc#L33

If we are afraid to break people who use explicitly reser= ved identifiers, then I think we'd be making a huge mistake. I agree th= at we should always minimize breaking people when it makes sense and I know= that people draw the line at different places, but we should at least be a= ble to make use of an identifier that has been reserved since the initial s= tandard.

I have to agree with = that. This is literally the whole point of reserving identifiers: so= that we can use them later. It's not like adding a keyword, where we n= eed to study the impact of making a change so as to minimize breakage.
<= br>If someone was using a reserved identifier (outside of a standard librar= y implementation), their code is wrong. We told them to stay out of this ar= ea, and they didn't. Their code breaking is not our fault, nor is it on= us to stay out of their way.

Now, one thing that's important in= this regard is that we should do a study on the impact of this change on s= tandard library implementations. Since we would obviously be taking away on= e of their identifiers.

--
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/94be2101-d81a-4ea2-bc78-cddc33cad37e= %40isocpp.org.
------=_Part_11499_695470842.1490722287676-- ------=_Part_11498_123145833.1490722287676-- .