220 32498 <99f88905-3bae-4c74-a3bf-71e80a65262c@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Allow Structured Binding Outside of Variable Declaration Date: Tue, 16 May 2017 14:37:49 -0700 (PDT) Lines: 99 Approved: news@gmane.org Message-ID: <99f88905-3bae-4c74-a3bf-71e80a65262c@isocpp.org> References: <10b21241-b683-44d5-82ce-90681b2643a4@isocpp.org> <08ff73f1-6989-393e-ee4e-8158af2e7bed@honermann.net> <20170516164245.GA16348@fukushima.lysator.liu.se> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2467_1993634323.1494970669661" X-Trace: blaine.gmane.org 1494970676 9954 195.159.176.226 (16 May 2017 21:37:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 16 May 2017 21:37:56 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBLXC5XEAKGQEKAT5LHY@isocpp.org Tue May 16 23:37:48 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f72.google.com ([209.85.214.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dAkA5-0002NY-PZ for gclcip-std-proposals@m.gmane.org; Tue, 16 May 2017 23:37:45 +0200 Original-Received: by mail-it0-f72.google.com with SMTP id g126sf114383432ith.5 for ; Tue, 16 May 2017 14:37:51 -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=1J2B/1+Rxp9IBUn1KQwzFTk9m+KaEhS5V4HDz2OW0aA=; b=ZkJ1SeAPS7Y0Dy2VqbDHs1foBJ8BXzWK4SZqnz6+0q/2J7FST3DpRXbiALMJueY4RJ qArYnTVYvEK07lnEbiXRbXk76ocu32y8xbwoQ8yn6hfklGCOeufd/lkq84pU05d2llUm rvgh3gkNQcK2OCM1mrkfqQVKmZU5YxqwAuq4dTnXmpbCMtIR2dAihxPRwxeYkOCkne5M gAQUTnxdCfXVZPwb0WGuANbn8PC+54e91qs3g3qR6qUX3skMurxU+R4JAHQdDA0FFC/9 w31jlHB76iBCPjpIdm7VTcMm3ngLj0rUOzh5sUBkgxD9fOAOXNJZMoPa76erAjqj1USi /z3Q== 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=1J2B/1+Rxp9IBUn1KQwzFTk9m+KaEhS5V4HDz2OW0aA=; b=NGQrM/qXNhw7nQ38i9uKVcgz0CU5WOoXSPjxYz1/cHIg/kJkFeqEXjJsmwLJs+fmN5 bC/QARNWkIK+PyrtFlJZp7Vpzu58v4mJMiwXCKSyi7iZsUyfN/JOgkoUMJkD6eTfUIKg RZOvU29V+Ch3fRKGrZh5yeXUcyJlgs/ppm1tS02VR0fsj/ETK4A7jrKIXM+VBDjHtDt4 4orZbPt22W+RalCmAzAbwfKgJwB47QZzEAjEYiQzibXOzGrgGlEjm21KnCJw2qsMSlbf 8w1N74+8a77DfOUD6lzWRarrdNKfQew/RrRS9yKxS0v0HfHJ5AYzQ8i9kXh/VZm4LOg4 7fjQ== 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=1J2B/1+Rxp9IBUn1KQwzFTk9m+KaEhS5V4HDz2OW0aA=; b=QRtbOiQucu8qDeKx+WxeCcDgHvMPsbhoWI+7MC2bJuT+YM+K8K7EKaoTe6tNDBrqt4 vhok7UsEnPqOz1CLWEtqyOE/CTLj2uLKlLUyw+tUKCQlswFLd+gsQykxdMVSDIb1d60P ITi5HKm9M1FbmA/lcI1C+aBXxPsU7i8VhOD4RpkvsTVD9wZqvGaO/dc98k5zjxdTEPss 0FiYrfBEkwdPcNECxHCFAXZV+lfk5i825ueZs4d+JlrWMrEpGP4lFkzB/cYf0zVlBqOk G9hS8292QogT4Rl1DO8Uj3Pj+WtMBenaksiBxXdnqYomOnDJr50sA6wiEt9DmL+mnWAx aXWA== X-Gm-Message-State: AODbwcCzXWlDG4kwEYWOW4Tr5kftWKFq4g29riZm+DWUSQGfs/RcopEK JVmjMgf6E6Hyzo1L X-Received: by 10.36.69.201 with SMTP id c70mr359469itd.17.1494970670988; Tue, 16 May 2017 14:37:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.56.90 with SMTP id r26ls2437079otd.0.gmail; Tue, 16 May 2017 14:37:50 -0700 (PDT) X-Received: by 10.157.55.133 with SMTP id x5mr2337otb.10.1494970670244; Tue, 16 May 2017 14:37:50 -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:32498 Archived-At: ------=_Part_2467_1993634323.1494970669661 Content-Type: multipart/alternative; boundary="----=_Part_2468_2075100966.1494970669661" ------=_Part_2468_2075100966.1494970669661 Content-Type: text/plain; charset="UTF-8" On Tuesday, May 16, 2017 at 5:12:32 PM UTC-4, Bengt Gustafsson wrote: > > Why not let a variable declaration inside a structured binding be a > variable declaration? If you want a reference to part of the hidden object > use & to create it. Then the compiler can be smart about not keeping the > hidden object if all parts were dug out to by value variables at the time > of binding: > > auto [WhatIWant x, int y] = something(); > > Here no succeding code can reach the hidden return value so it can be > destroyed. > > auto [WhatIWant& x, y] = something(); > > Here the first returned value is checked to be a WhatIWant (or subclass) > while y is typed from the rhs. The compiler will easily deduce that the > hidden return value has to be kept until the scope exits. > Here's the problem. In this case, `decltype(x)` is a reference; it is *always* a reference. What is `decltype(y)`? Well, that depends on what `something()` returns. If it returns a product type that involves `get` calls, then it's a reference. If it returns a struct (without `get` and such) or an array type, then `decltype(y)` is *not a reference*. But remember: `decltype(x)` is *always* a reference; that is what you declared, after all. The problem is that bitfields can undergo structured binding. And you *cannot* get a reference to a bitfield. So that's... problematic. What we want is the structured binding behavior for the name to remain the same, yet still allow the type that the name is assigned to to be checked. And `WhatIWant &x` is not a good way to spell that. -- 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/99f88905-3bae-4c74-a3bf-71e80a65262c%40isocpp.org. ------=_Part_2468_2075100966.1494970669661 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, May 16, 2017 at 5:12:32 PM UTC-4, Bengt Gustaf= sson wrote:
Wh= y not let a variable declaration inside a structured binding be a variable = declaration? If you want a reference to part of the hidden object use &= to create it. Then the compiler can be smart about not keeping the hidden = object if all parts were dug out to by value variables at the time of bindi= ng:

=C2=A0 =C2=A0 auto [WhatIWant x, int y] =3D somethin= g();

Here no succeding code can reach the hidden r= eturn value so it can be destroyed.

=C2=A0 =C2=A0 = auto [WhatIWant& x, y] =3D something();

Here t= he first returned value is checked to be a WhatIWant (or subclass) while y = is typed from the rhs. The compiler will easily deduce that the hidden retu= rn value has to be kept until the scope exits.

Here's the problem. In this case, `decltype(x)` is a reference; it= is always a reference. What is `decltype(y)`? Well, that depends on= what `something()` returns. If it returns a product type that involves `ge= t` calls, then it's a reference. If it returns a struct (without `get` = and such) or an array type, then `decltype(y)` is not a reference.
But remember: `decltype(x)` is always a reference; that is wha= t you declared, after all. The problem is that bitfields can undergo struct= ured binding. And you cannot get a reference to a bitfield. So that&= #39;s... problematic.

What we want is the structured binding behavio= r for the name to remain the same, yet still allow the type that the name i= s assigned to to be checked. And `WhatIWant &x` is not a good way to sp= ell that.

--
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/99f88905-3bae-4c74-a3bf-71e80a65262c= %40isocpp.org.
------=_Part_2468_2075100966.1494970669661-- ------=_Part_2467_1993634323.1494970669661-- .