220 32493 <6bee864f-4ff6-4e1d-9425-1ffd0ade99b1@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 10:53:42 -0700 (PDT) Lines: 312 Approved: news@gmane.org Message-ID: <6bee864f-4ff6-4e1d-9425-1ffd0ade99b1@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_2302_976405073.1494957222690" X-Trace: blaine.gmane.org 1494957224 5354 195.159.176.226 (16 May 2017 17:53:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 16 May 2017 17:53:44 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBJ7Z5TEAKGQEC7JRTVQ@isocpp.org Tue May 16 19:53:40 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 1dAgfC-0001Ew-K8 for gclcip-std-proposals@m.gmane.org; Tue, 16 May 2017 19:53:38 +0200 Original-Received: by mail-ua0-f200.google.com with SMTP id e55sf54364454uaa.2 for ; Tue, 16 May 2017 10:53:44 -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=9C1OkLGGXxv+IZCQQhWuGDgnTGWD1ajaWwk48JyewdQ=; b=Dj/eFN1ft7iJsVdINnQNf6EvapGlV7q+72siHasxRyu422/M+DT6ooBi6OZ7yGqpfL zbIIRmBdqnIPRwOQJX4F/iqjakDeYgjCGGl3qTjPX1WncCdp1L6wiwysl1cp8ENKB0xp +/cpoa2OrfTQNLXUB2SH7GWV8zJADlNN5dX26LXN0rSAIrlUj6dgabFGtMXINllnL5oM ZI3rn2AI24rgVSLMXUK68QnzMdDl34HchrkkYzKNY14cA1toy2X787q55uaOgwUKtClk HDNxtGfT5Y/kqFL+4JlHhTWK/Sj1g/7+f0KYgoHsSN2Ecv0NxQpC7TzIE/0pGacxD3Wi nGuw== 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=9C1OkLGGXxv+IZCQQhWuGDgnTGWD1ajaWwk48JyewdQ=; b=LmNhqdx0rxIaPFxRiGDpEoJzyJ+rXE3sOdNos3ZEv/8zQWj9weVFR7bETfW2YV1aj/ lS2KK2ZFXnuLnCy2S9Vi0QnnNx9JKygY6J+AxBQGyFlqUCR2KtmteatAHj/AdyjTG9tD fmoqGIu57dMMv+GFoWSMLebzicuzIEeDTe5+bcfeqxVK+q3+jPs6hI38TljatDWqWCzR A69zjZl/8kju5Y09RWnsDgdV5nXTpYbPTK7DT6T7iXFqxoQHoC1S6T1DU7o/MYT7STb4 ZmnUt8Bzl6YloiU25Nl490iO9HDQ+hs7gcUfX6lNQ+5K735qRfYbGBJqJ5BgaX8MKRev 3Znw== 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=9C1OkLGGXxv+IZCQQhWuGDgnTGWD1ajaWwk48JyewdQ=; b=ZI9EAggtJLEwpa/PAf0dgYII380F20amEWwDtLjAn/HDagLC5quYcHBaI4DHR4oGv2 yhpQXTn4SoJd6LyveiTIn9lTmSU7Q32E8kBw0syqHE5f3J4m4wFDi72HmdROR8qyL3aW gqtyPN+Ix3xI6N6NLkBWABTrU1e4A4W8A4HNkkolnUM/PnCs5mD9P2rnG0HiGnl8iP+2 S7U+6kjWplZHZPQTi84sxliMIZTCDyQv1gfl/U25n6Ez6N5vobh8CwoK1tGQDskByEe1 Eg6axKgVSUGCc474B9eDt82DvBrnanhmA5/LrGJhLJpDYOMe1uGAAeUaYmd8tTti+0Ps OmIg== X-Gm-Message-State: AODbwcAIUEwB79RVOP6E66lZUpGKDmoeDC14Jm4kMIPJz/2sIBoxxjTh lss5B76hMww3oQ== X-Received: by 10.176.3.230 with SMTP id 93mr5176311uau.19.1494957224083; Tue, 16 May 2017 10:53:44 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.4.20 with SMTP id 20ls1979759otc.41.gmail; Tue, 16 May 2017 10:53:43 -0700 (PDT) X-Received: by 10.157.33.109 with SMTP id l42mr280713otd.7.1494957223130; Tue, 16 May 2017 10:53:43 -0700 (PDT) In-Reply-To: <20170516164245.GA16348@fukushima.lysator.liu.se> 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:32493 Archived-At: ------=_Part_2302_976405073.1494957222690 Content-Type: multipart/alternative; boundary="----=_Part_2303_2138458239.1494957222691" ------=_Part_2303_2138458239.1494957222691 Content-Type: text/plain; charset="UTF-8" On Tuesday, May 16, 2017 at 12:42:50 PM UTC-4, Magnus Fromreide wrote: > > On Tue, May 16, 2017 at 12:36:52PM -0400, Tom Honermann wrote: > > On 05/16/2017 11:30 AM, Ville Voutilainen wrote: > > >On 16 May 2017 at 18:25, Tom Honermann > wrote: > > >>>> auto [k -> Key, =in] = parseKey(in); > > >>>> if (*in++ != ',') throw Failure(); > > >>>> auto [v -> Value, =in] = parseValue(in); > > >>>> if (*in++ != ')') throw Failure(); > > >>>> return {KVPair(k, v), in}; > > >>>> } > > >>> > > >>>Well, with the idea I cobbled together, I can write > > >>> > > >>>auto [x, =k->Key] = parseKey(); > > >>> > > >>>and it means something completely different, because -> is a member > > >>>access operator. So we can safely > > >>>assume that k is an entity that supports operator->, and my binding > > >>>there assigns to k->Key. It's such fun > > >>>to try to extend a language where all good syntaxes have been taken a > > >>>long time ago. :) > > >>> > > >>Oh, well, the solution to that is, of course, keyword spackling. > > >> > > >>auto [x, =k-> typename Key] = parseKey(); > > >> > > >>:) > > > > > >What makes you think Key is a typename? :P > > > > > Because when I wrote that, I was intending to write a type constraint > and > > not a member access. You can tell because I put 'typename' there :P > > > > Also because 'Key' starts with an uppercase letter but isn't all upper > case > > letters. As we all know, that means it unambiguously designates a type. > > > > Actually, a type constraint doesn't makes much sense for an assignment > > binding, and a member access doesn't make much sense for a structured > > binding, so perhaps there is no ambiguity after all. > > > > auto [x -> SomeType, =k->Key] = parseKey(); // Constrains 'x' to > 'SomeType', assigns 'k->Key' > > > > Yes, there is a certain amount of ick factor there. > > But why invent a new way to declare/constrain types that is almost unheard > about? > > What is wrong with the good old way? > > auto [SomeType x, =k->Key] = parseKey(); > Allow me to attempt to explain what I think Tom Honermann is trying to say. If you do: SomeType z = expr; `z` shall be a variable of type `SomeType`. It will not be a reference; it will be an object, initialized by `expr`. If `expr` is not implicitly convertible to `SomeType`, then you get a compile error. If `expr` is an lvalue, then you get a copy; if it is an xvalue, you get a move; if it is a prvalue, you just initialize `z` in-situ. If you do: auto [x, y] = expr; Assuming that the first member of `expr` is of type `SomeType` (an object or reference), then `x` will effectively be a reference to that `SomeType` subobject. Note that `x` won't necessarily be an *actual reference*, but it will act like one. Most important of all, `x` will not provoke a copy or move (outside of what is needed to initialize the hidden variable). So, what does this mean: auto [SomeType x, y] = expr; `SomeType x` looks like a variable declaration. It looks like `x` ought to be an object, one that is separate from the product type created by `expr`. That is, this *looks like* it ought to be equivalent to: auto __hidden__ = expr; SomeType x = get<0>(__hidden__); //Copies the value auto &y = get<1>(__hidden__); //Gets a reference However, I believe that Tom is arguing that this is not how it *should* behave. That it ought to behave exactly like the `auto [x, y]` case, except with a compilation error if the type isn't `SomeType`. But since `SomeType x` looks like a variable declaration, people will expect it to act like one. By contrast, `x -> SomeType` is new syntax. This new syntax would explicitly mean "just check to see if its the right type; don't create an object." I can agree with this logic in some sense. I agree that we do need a way to say "create a structured binding member, but also fail to compile if it is not of this type". At the same time, I'm fine with spelling that `SomeType &x` (or && as appropriate). -- 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/6bee864f-4ff6-4e1d-9425-1ffd0ade99b1%40isocpp.org. ------=_Part_2303_2138458239.1494957222691 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, May 16, 2017 at 12:42:50 PM UTC-4, Magnus From= reide wrote:
On Tue, May 16, 20= 17 at 12:36:52PM -0400, Tom Honermann wrote:
> On 05/16/2017 11:30 AM, Ville Voutilainen wrote:
> >On 16 May 2017 at 18:25, Tom Honermann <t...@honermann.net&= gt; wrote:
> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto [k -> = Key, =3Din] =3D parseKey(in);
> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (*in++ !=3D= ',') throw Failure();
> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto [v -> = Value, =3Din] =3D parseValue(in);
> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (*in++ !=3D= ')') throw Failure();
> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return {KVPair= (k, v), in};
> >>>> =C2=A0 =C2=A0 =C2=A0 }
> >>>
> >>>Well, with the idea I cobbled together, I can write
> >>>
> >>>auto [x, =3Dk->Key] =3D parseKey();
> >>>
> >>>and it means something completely different, because -= > is a member
> >>>access operator. So we can safely
> >>>assume that k is an entity that supports operator->= , and my binding
> >>>there assigns to k->Key. It's such fun
> >>>to try to extend a language where all good syntaxes ha= ve been taken a
> >>>long time ago. :)
> >>>
> >>Oh, well, the solution to that is, of course, keyword spac= kling.
> >>
> >>auto [x, =3Dk-> typename Key] =3D parseKey();
> >>
> >>:)
> >
> >What makes you think Key is a typename? :P
> >
> Because when I wrote that, I was intending to write a type constra= int and
> not a member access. =C2=A0You can tell because I put 'typenam= e' there :P
>=20
> Also because 'Key' starts with an uppercase letter but isn= 't all upper case
> letters. =C2=A0As we all know, that means it unambiguously designa= tes a type.
>=20
> Actually, a type constraint doesn't makes much sense for an as= signment
> binding, and a member access doesn't make much sense for a str= uctured
> binding, so perhaps there is no ambiguity after all.
>=20
> auto [x -> SomeType, =3Dk->Key] =3D parseKey(); =C2=A0// Con= strains 'x' to 'SomeType', assigns 'k->Key'
>=20
> Yes, there is a certain amount of ick factor there.

But why invent a new way to declare/constrain types that is almost unhe= ard
about?

What is wrong with the good old way?

auto [SomeType x, =3Dk->Key] =3D parseKey();

Allow me to attempt to explain what I think Tom H= onermann is trying to say.

If you do:

SomeType z =3D expr;

`z` shall be a varia= ble of type `SomeType`. It will not be a reference; it will be an object, i= nitialized by `expr`. If `expr` is not implicitly convertible to `SomeType`= , then you get a compile error. If `expr` is an lvalue, then you get a copy= ; if it is an xvalue, you get a move; if it is a prvalue, you just initiali= ze `z` in-situ.

If you do:

auto [x= , y= ] =3D expr;

Assuming that th= e first member of `expr` is of type `SomeType` (an object or reference), th= en `x` will effectively be a reference to that `SomeType` subobject. Note t= hat `x` won't necessarily be an actual reference, but it will ac= t like one. Most important of all, `x` will not provoke a copy or move (out= side of what is needed to initialize the hidden variable).

So, what = does this mean:

auto = [SomeType<= /span> x, y] =3D expr;

`SomeType x` looks like a variable = declaration. It looks like `x` ought to be an object, one that is separate = from the product type created by `expr`. That is, this looks like it= ought to be equivalent to:

auto __hidden__ =3D expr;
Som= eType x =3D get<0>(__hidden__); =C2=A0//Copies the value
auto &= ;y = =3D get<1>(__hidden__); =C2=A0//Gets a reference

However, I believe that= Tom is arguing that this is not how it should behave. That it ought= to behave exactly like the `auto [x, y]` case, except with a compilation e= rror if the type isn't `SomeType`. But since `SomeType x` looks like a = variable declaration, people will expect it to act like one.

By cont= rast, `x -> SomeType` is new syntax. This new syntax would explicitly me= an "just check to see if its the right type; don't create an objec= t."

I can agree with this logic in some sense. I agree that we = do need a way to say "create a structured binding member, but also fai= l to compile if it is not of this type". At the same time, I'm fin= e with spelling that `SomeType &x` (or && as appropriate).
=

--
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/6bee864f-4ff6-4e1d-9425-1ffd0ade99b1= %40isocpp.org.
------=_Part_2303_2138458239.1494957222691-- ------=_Part_2302_976405073.1494957222690-- .