220 31969 <1380e942-6c0c-4bae-9042-d3e5064e96d8@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Barry Revzin Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: This variable should not be named: an identifier (not) to remember Date: Mon, 3 Apr 2017 12:37:28 -0700 (PDT) Lines: 91 Approved: news@gmane.org Message-ID: <1380e942-6c0c-4bae-9042-d3e5064e96d8@isocpp.org> References: <985b9b2a-c734-45eb-95f4-db4dc0d309a1@isocpp.org> <1491170458.9U0G8TLsOk@tjmaciei-mobl1> <10c2c556-b6bb-4714-83bc-7b0ac8fd4143@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_816_156274550.1491248248106" X-Trace: blaine.gmane.org 1491248250 15777 195.159.176.226 (3 Apr 2017 19:37:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 3 Apr 2017 19:37:30 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCJJTG7CS4ARB6OIRLDQKGQEDHJLEQA@isocpp.org Mon Apr 03 21:37:26 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 1cv7n2-0003KB-1Q for gclcip-std-proposals@m.gmane.org; Mon, 03 Apr 2017 21:37:24 +0200 Original-Received: by mail-oi0-f72.google.com with SMTP id d27sf106588758oic.16 for ; Mon, 03 Apr 2017 12:37:30 -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=Vt0nRMFldvB21P50I8YICiPFbnelNqUprzoBXe65Tvc=; b=xwSD6nURFghtstVM9+jbzvmSqznFvl97TxZzlTyKgZLY2oZMtfO+gl3telMUIFPsil /uWmVpLoo59yBz06jthW9zlY/+u3NKOlyPsD6GfLxlcY8c8poQCpBw5YjSeWKNr3iuxC aCb7byYUcLLWfwpynyILLz78PmQioTm4m18NZAJ93ovEbJGfKZD71HMpzuAJRZzTZPe1 w2Wo9Ouj0Y781DQp/EBl/Ey2e9Aw21H9zJHAmhL3GyLSRfwftwmdCU90d7yZ4kA4G9Zq bgWnmS5J+TpoyFjVrzt7i8dCKohzmplRZpWsz7Ab0wSR/bnrgpp6PHcjE5BxdX+UYsQd cmZg== 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=Vt0nRMFldvB21P50I8YICiPFbnelNqUprzoBXe65Tvc=; b=BUlQ8Y56XuciAc9dF3AkVPM6yy0//2gpe3raezjGQahoR/72VK102xLnKPvSV+yWyT g87fTP8L+IKh+/8WzYj2EFpvR3lwy0x8dzR1qYo31s9BwuU57K/C4Dd8v0m6LIUmRzJH IlRkcsGF4EkN6X3rb5lnbRbcnf2d9OCiBygaYCvHI6usxZ/bJ9HH+dv12190gQqV3O2W vZNZYqepR+RJBAwGTLRTy9/7zXR9Cllk8cf9bupwA0vW+Yq5wzrQ28yjjwKS247P195n XgHmACfs1i/iSIidzRGt70ebIFFj94F3zRrS1k3nl3eJjE/ohO1cUpLE1D5ZAGQsZYNm e9AA== 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=Vt0nRMFldvB21P50I8YICiPFbnelNqUprzoBXe65Tvc=; b=pZ3GLkrxfy2Cg0MCLEq9UHviNyOdufbL5QEqa/IuaG+evX4GzniC6fLolGsjh7DYWs 1eNQqNtN8ttXK7xy7Gcm3XOQSRdgM+N0MfmVNoYf1Qy0mnRI2W5HH66rF8TW3kFEXlpE GvXDlws087p3n8OT8aweYNuCiEOCYPbhyIcfUkqX9hNHo2XWonJUUHeNPgfrZC2KQrei hqOvoQtOQPBK0FjdoZ1o57EG0ItlHI5rrXv6SLgcOTHGfh0gHfusOwO5f59aU94TQ1/n zyaeaG2fEqIacCU1tB0NrOmuqITXREIXY3K5WbMkPofDRkpwLJt626pikQwMUOH5KyeK JuoA== X-Gm-Message-State: AFeK/H0vBbb2hu8Dmu0KzZME/ou7YuHqoZi6skA5MTBz0geJyHyh3jGmwah2CfWs2e8RnQ== X-Received: by 10.157.45.98 with SMTP id v89mr8413855ota.105.1491248249765; Mon, 03 Apr 2017 12:37:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.35.166 with SMTP id t35ls1925635otb.11.gmail; Mon, 03 Apr 2017 12:37:28 -0700 (PDT) X-Received: by 10.157.18.211 with SMTP id g77mr186067otg.8.1491248248933; Mon, 03 Apr 2017 12:37:28 -0700 (PDT) In-Reply-To: X-Original-Sender: Barry.Revzin@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:31969 Archived-At: ------=_Part_816_156274550.1491248248106 Content-Type: multipart/alternative; boundary="----=_Part_817_810417299.1491248248106" ------=_Part_817_810417299.1491248248106 Content-Type: text/plain; charset=UTF-8 > > >> If it is an identifier, then it must be a *reserved* identifier, to >> minimize code breakage when we change its meaning. >> > > As I pointed out, this is an incorrect conclusion. There is no necessity > for any code breakage here, and there is no need to pick a reserved > identifier: the core functionality of this proposal does not require that > the identifier be unusable within its scope, and if we don't add that > restriction, this is strictly an extension. > > I think the logical extreme of this idea is to not pick any identifier at all - simply allow hiding declarations in the same scope. So from the original paper's examples, using __ to declare multiple variables in the same scope just works not because of some special magic bestowed upon the identifier "__", but instead because you're actually declaring multiple variables in the same scope named "__". You'd have no way of accessing the earlier versions of __, but then you don't want to anyway. I don't know how to get the compiler to not warn against not using the last incarnation of __ though. That just may be a "teach the compiler that this is a convention that people want to use" kind of thing. We'd have to change the scope rules for names, but I'm not sure that's any worse than bestowing magic language meaning on a specific identifier. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1380e942-6c0c-4bae-9042-d3e5064e96d8%40isocpp.org. ------=_Part_817_810417299.1491248248106 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If it is an identifier, then it must be a reserved= identifier, to minimize code breakage when we change its meaning.

As I pointed out, this is an incorrect = conclusion. There is no necessity for any code breakage here, and there is = no need to pick a reserved identifier: the core functionality of this propo= sal does not require that the identifier be unusable within its scope, and = if we don't add that restriction, this is strictly an extension.
<= div>

I think th= e logical extreme of this idea is to not pick any identifier at all - simpl= y allow hiding declarations in the same scope. So from the original paper&#= 39;s examples, using __ to declare multiple variables in the same scope jus= t works not because of some special magic bestowed upon the identifier &quo= t;__", but instead because you're actually declaring multiple vari= ables in the same scope named "__". You'd have no way of acce= ssing the earlier versions of __, but then you don't want to anyway. I = don't know how to get the compiler to not warn against not using the la= st incarnation of __ though. That just may be a "teach the compiler th= at this is a convention that people want to use" kind of thing.=C2=A0<= /div>

We'd have to change the scope rules for names,= but I'm not sure that's any worse than bestowing magic language me= aning on a specific identifier.=C2=A0

--
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/1380e942-6c0c-4bae-9042-d3e5064e96d8= %40isocpp.org.
------=_Part_817_810417299.1491248248106-- ------=_Part_816_156274550.1491248248106-- .