220 32060 article Path: news.gmane.org!.POSTED!not-for-mail From: Domen Vrankar Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: This variable should not be named: an identifier (not) to remember Date: Mon, 10 Apr 2017 08:52:17 +0200 Lines: 107 Approved: news@gmane.org Message-ID: References: <985b9b2a-c734-45eb-95f4-db4dc0d309a1@isocpp.org> <1491170458.9U0G8TLsOk@tjmaciei-mobl1> <10c2c556-b6bb-4714-83bc-7b0ac8fd4143@isocpp.org> <5d35116c-5974-417a-840f-3dc714eae601@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c16b40f2bd4d054cca6cd5 X-Trace: blaine.gmane.org 1491807181 10293 195.159.176.226 (10 Apr 2017 06:53:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 10 Apr 2017 06:53:01 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCHJ3Z4NUUFBBS6XVTDQKGQEOVNZXCY@isocpp.org Mon Apr 10 08:52:54 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f200.google.com ([209.85.217.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cxTC2-0002Zi-IG for gclcip-std-proposals@m.gmane.org; Mon, 10 Apr 2017 08:52:54 +0200 Original-Received: by mail-ua0-f200.google.com with SMTP id a1sf14276697uaf.22 for ; Sun, 09 Apr 2017 23:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references: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=2LokLGfudxwFnN/Ol3yCEBUjEN416eiHdMFkuOLWzy8=; b=npdzOF6K7FP3heC87JWuqJw89iViUe+APB7sri8w72mherIqbnFFK1tM8K7OkaeHK6 zrx1wTd5l7lbCP4a8rbbea1wvypCgVrG9TjyWhBu2BpMKDGt/WKq2Dl8+IcjLPrMM0dv uzttZSzLgoYW0KN7W++LshVHN1lv+KH6642ycxDnxQUSJAUblvCKChoSyf85fuPlhO4O AoXtDelWgXGm1pKHfCrgd8Lc1lLbAZSwWtpqLcmYU/8ZXRAES+rqk2HDZiJxKgA0McwM LSYNiSPmn3Gaxal8t9Mt4elZRlsKGxaLGfH9QnX0/GUJ0n2sWQypq/R1r7KfZN9yBIhM nEmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references: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=2LokLGfudxwFnN/Ol3yCEBUjEN416eiHdMFkuOLWzy8=; b=NC7nDRgB8VTPXtE27gM96sHotFYYs3sfY7ZgUMMrNzmcUUS7jPxZmKuxsv/5B3ccHO OU/obJYs197jWwTU8SJU7MFxs2BXSdv9AMvTtagre1m7j+bk3BaE+m3iKvttUIiZv2+/ nIrLTtnK5vE7FJIydH6XfAz7Fzd/3kAXNx/tGFCcWsCa3R7mElk9Nt1WpCscSon0d6/T LqtbOpRf18GDLpA/0paK2DvSJWS/IzJUpKCH+92t31k3XxWgOFyCzocNX4QFVOFH1lY1 1tJK2efTJkCSK0PnK5C1VEM2i5+DK+0rjl40rAA0B/FKMvjxd+eunebuASutnTW3C0SO hD4A== X-Gm-Message-State: AFeK/H3glNyesfxxrLasBDcA253dP5NQ46r1dDMgtHjvgcjB3Oca/Apb9HZi0WxZ5uHWMQ== X-Received: by 10.31.49.6 with SMTP id x6mr14020027vkx.28.1491807180226; Sun, 09 Apr 2017 23:53:00 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.9.165 with SMTP id 37ls548859ioj.25.gmail; Sun, 09 Apr 2017 23:52:58 -0700 (PDT) X-Received: by 10.36.238.71 with SMTP id b68mr2503339iti.23.1491807178895; Sun, 09 Apr 2017 23:52:58 -0700 (PDT) Original-Received: from mail-io0-x231.google.com (mail-io0-x231.google.com. [2607:f8b0:4001:c06::231]) by mx.google.com with ESMTPS id r125si6958273itg.4.2017.04.09.23.52.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Apr 2017 23:52:58 -0700 (PDT) Received-SPF: pass (google.com: domain of domen.vrankar@gmail.com designates 2607:f8b0:4001:c06::231 as permitted sender) client-ip=2607:f8b0:4001:c06::231; Original-Received: by mail-io0-x231.google.com with SMTP id t68so50545311iof.0 for ; Sun, 09 Apr 2017 23:52:58 -0700 (PDT) X-Received: by 10.107.47.130 with SMTP id v2mr46643214iov.201.1491807178503; Sun, 09 Apr 2017 23:52:58 -0700 (PDT) Original-Received: by 10.79.20.133 with HTTP; Sun, 9 Apr 2017 23:52:17 -0700 (PDT) In-Reply-To: X-Original-Sender: Domen.Vrankar@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of domen.vrankar@gmail.com designates 2607:f8b0:4001:c06::231 as permitted sender) smtp.mailfrom=domen.vrankar@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:32060 Archived-At: --001a11c16b40f2bd4d054cca6cd5 Content-Type: text/plain; charset=UTF-8 2017-04-10 1:10 GMT+02:00 Alberto Barbati : > > Il giorno 03 apr 2017, alle ore 00:45, Nicol Bolas > ha scritto: > > This proposal is about having a scope-bound object which *cannot be later > referenced*, which has a name that is generated by the compiler. That's > what the proposal is for: "for all variables whose name is not important > and that is no longer needed after declaration". > > > Sorry to have left the thread for so long. After some pondering, although > the __ approach is still on the table, I have decided to explore a bit > further other options that do not require reserving an identifier, in > particular the one suggested by Nicol Bolas. The fact is that I realized > C++17 already has a tool that creates an object that cannot be > referenced... that tool is decomposition declaration itself. With just > three tweaks, which would make for a pure extension, we can achieve both > goals of my proposal. > > Tweak #1 > > Allow identifiers in a decomposition declaration to be omitted. So in > > auto [x, , z] = func(); > > the second element is not named so the corresponding element needs not be > bound and get<1>() is guaranteed not to be called (however, we might still > check that it might have been called, for consistency). > > This tweak alone solves goal #2 of the proposal and is probably more > elegant: since there's no name, there's little room for misunderstanding > about the semantic. > Won't this be annoying to read? It might be just me but I would still prefer a placeholder for something like that. Regards, Domen -- 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/CAKgx6BK_agZFNJSkvhkGn6c6u0PJkGhxBoYzu3t%3DFhj2zPj1mw%40mail.gmail.com. --001a11c16b40f2bd4d054cca6cd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2017-04-10 1:10 GMT+02:00 Alberto Barbati <alberto= barbati@gmail.com>:

=
Il giorno 03 apr 2017, alle ore 00:45, Nicol Bolas <jmckesson@gmail.com> ha sc= ritto:

This proposal is about h= aving a scope-bound object which cannot be later referenced, which h= as a name that is generated by the compiler. That's what the proposal i= s for: "for all variables whose name is not important and that is no l= onger needed after declaration".

Sorry to h= ave left the thread for so long. After some pondering, although the __ appr= oach is still on the table, I have decided to explore a bit further other o= ptions that do not require reserving an identifier, in particular the one s= uggested by Nicol Bolas. The fact is that I realized C++17 already has a to= ol that creates an object that cannot be referenced... =C2=A0that tool is d= ecomposition declaration itself. With just three tweaks, which would make f= or a pure extension, we can achieve both goals of my proposal.
Tweak #1

Allow identifiers in a decom= position declaration to be omitted. So in

=C2=A0 = =C2=A0 auto [x, , z] =3D func();

the second elemen= t is not named so the corresponding element needs not be bound and get<1= >() is guaranteed not to be called (however, we might still check that i= t might have been called, for consistency).

This t= weak alone solves goal #2 of the proposal and is probably more elegant: sin= ce there's no name, there's little room for misunderstanding about = the semantic.

Won&#= 39;t this be annoying to read? It might be just me but I would still prefer= a placeholder for something like that.

Regards,

<= /div>
Domen

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BK_agZFNJ= SkvhkGn6c6u0PJkGhxBoYzu3t%3DFhj2zPj1mw%40mail.gmail.com.
--001a11c16b40f2bd4d054cca6cd5-- .