220 31923 article Path: news.gmane.org!.POSTED!not-for-mail From: Viacheslav Usov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: multiple identically named variables Date: Sun, 2 Apr 2017 14:04:12 +0200 Lines: 87 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c04420e4febe2054c2dd71a X-Trace: blaine.gmane.org 1491134656 21876 195.159.176.226 (2 Apr 2017 12:04:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 2 Apr 2017 12:04:16 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBDU6VRPKW4BBBPORQPDQKGQEG5EOHLQ@isocpp.org Sun Apr 02 14:04:12 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f200.google.com ([209.85.220.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cueEr-0004qR-2z for gclcip-std-proposals@m.gmane.org; Sun, 02 Apr 2017 14:04:09 +0200 Original-Received: by mail-qk0-f200.google.com with SMTP id k139sf12401221qke.22 for ; Sun, 02 Apr 2017 05:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject: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=QsxnNzp5AswclGMa+x/vaPSeUQPHQRtML/FcDZ0sknA=; b=LfqxFk1QDhn5e4gRWAJirATyM4nBHqAzMbaS3m0Ne661lChiwhAOQZja0X9OllzSB1 icqxLVP+fDNJZDF/1b0FOPQYSyuejh6x3wnIebrVZCzgYypliXo/VArsxIr9IYmIXJeV wzziQkPbbzivCwNgrRj97+wpavSTMdGJjDC2h+uKhv6FDzy1CAYfj14zV2Hoy9OGNkCW Bg663t/T2oA0vMtWIEc6SYkWgLGvBZsu1E7o28ckaR7HIYLl0SBTiZ6vBXty/4h9TpYZ TRba0p5d9ivIJNxlpzB9fTxWgOIhaziHyguqSDeYk3vt5MeKe7rJ/5setUUH2V6dw2ye g3og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject: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=QsxnNzp5AswclGMa+x/vaPSeUQPHQRtML/FcDZ0sknA=; b=HY4xMvVqkTveJjW1Ytq7pG0/JSdxC5ac6GfqtuVb0IfDDc3jwxR8iwiG4RFLlBRYKM Wf5Zj4SpQtcjHr6lTTvnxhRHsbC0CwHA58EtGYe9QJaLSlZ19tt+M8X7/sU4UfqT5vLB 0ghrOszfJ3UbtZBib/FGMQaABJ7HNdPOLLiX3ckGuuVstdW4iF0ROg+ODb1npCO1es/3 uE3yVZjuj7mNgzEonZrc70lF79gZfFkbrr/yC+VmM0dXqkYPxlIRe37bFRPSEQN9up15 YrlONiGWsO/wVGk9zgutLKRaIBx9fQ6labyNJcy7GB1WESeQhMjk4HOtkQ+YKeWHfK7M urZA== X-Gm-Message-State: AFeK/H2xLUH2Qv8Yn62R6j+wVZvLgf7mhMAHVtaUcXqQWLmdZMY4p9vsTf0aOOyLaw2LEA== X-Received: by 10.200.55.241 with SMTP id e46mr4991604qtc.22.1491134654630; Sun, 02 Apr 2017 05:04:14 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.18.246 with SMTP id g109ls5934739otg.44.gmail; Sun, 02 Apr 2017 05:04:13 -0700 (PDT) X-Received: by 10.237.41.229 with SMTP id o92mr11665722qtd.90.1491134653760; Sun, 02 Apr 2017 05:04:13 -0700 (PDT) Original-Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com. [2607:f8b0:400d:c09::235]) by mx.google.com with ESMTPS id 23si9476202qkk.14.2017.04.02.05.04.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Apr 2017 05:04:13 -0700 (PDT) Received-SPF: pass (google.com: domain of via.usov@gmail.com designates 2607:f8b0:400d:c09::235 as permitted sender) client-ip=2607:f8b0:400d:c09::235; Original-Received: by mail-qk0-x235.google.com with SMTP id g195so23981876qke.2 for ; Sun, 02 Apr 2017 05:04:13 -0700 (PDT) X-Received: by 10.55.186.134 with SMTP id k128mr10754547qkf.40.1491134653129; Sun, 02 Apr 2017 05:04:13 -0700 (PDT) Original-Received: by 10.12.157.78 with HTTP; Sun, 2 Apr 2017 05:04:12 -0700 (PDT) X-Original-Sender: via.usov@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of via.usov@gmail.com designates 2607:f8b0:400d:c09::235 as permitted sender) smtp.mailfrom=via.usov@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:31923 Archived-At: --94eb2c04420e4febe2054c2dd71a Content-Type: text/plain; charset=UTF-8 In a recent thread here, there was a proposal for a special variable name __ that could be used multiple times within a block, essentially introducing a new case in [basic.scope.hiding]. Now the question is, why can't we introduce such a case there for *any* local variable? Then one would be able to define multiple identically named variables within one and the same scope; all except the latest will be hidden. That will trivially address all of the points of the __ proposal. For example: lock_guard g(mutex1); lock_guard g(mutex2); auto [a, x, x, b] = foo(); The advantage of that would be in the avoidance of magic variable names, and having to reach consensus as to what they should be. The disadvantage... I am actually not that sure there is a serious disadvantage. An obvious point can be made that accidental typos might introduce subtle errors. But the same kind of accidental typos is possible today, except that the accidental typo must reside in a nested block. However, lengthy and flat blocks are rare in regular C++. A typical block either is short and flat, or is lengthy and contains nested blocks, so the typos are more likely to be made in nested blocks, so no significant new risk is introduced. Other opinions? Cheers, V. -- 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/CAA7YVg36Lk6wGAHNcWky-NCQpPPKmVq9sAnWrXYmj-DLqzTObA%40mail.gmail.com. --94eb2c04420e4febe2054c2dd71a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In a recent thread here, there was a proposal for a specia= l variable name __ that could be used multiple times within a block, essent= ially introducing a new case in [basic.scope.hiding].

No= w the question is, why can't we introduce such a case there for any<= /i> local variable? Then one would be able to define multiple identically n= amed variables within one and the same scope; all except the latest will be= hidden.

That will trivially address all of the po= ints of the __ proposal. For example:

lock_guard g= (mutex1);
lock_guard g(mutex2);

auto [a,= x, x, b] =3D foo();

The advantage of that would b= e in the avoidance of magic variable names, and having to reach consensus a= s to what they should be.

The disadvantage... I am= actually not that sure there is a serious disadvantage. An obvious point c= an be made that accidental typos might introduce subtle errors. But the sam= e kind of accidental typos is possible today, except that the accidental ty= po must reside in a nested block. However, lengthy and flat blocks are rare= in regular C++. A typical block either is short and flat, or is lengthy an= d contains nested blocks, so the typos are more likely to be made in nested= blocks, so no significant new risk is introduced.

Other opinions?

Cheers,
V.

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg36Lk6wGAHN= cWky-NCQpPPKmVq9sAnWrXYmj-DLqzTObA%40mail.gmail.com.
--94eb2c04420e4febe2054c2dd71a-- .