220 34181 <3509394f-e995-41d1-8fe0-3e7d8ecfe63e@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Curious Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Structured bindings with polymorphic lambdas Date: Mon, 28 Aug 2017 11:14:03 -0700 (PDT) Lines: 335 Approved: news@gmane.org Message-ID: <3509394f-e995-41d1-8fe0-3e7d8ecfe63e@isocpp.org> References: <8497b31b-7c9d-4334-ac22-0809c958cb93@isocpp.org> <15a70d94-e039-4f82-ba01-bde9d3fbacbd@isocpp.org> <6b50933d-291b-4b47-8c0c-82c97d9cb406@isocpp.org> <348b59eb-c288-482e-a7f4-473d8f1fbfea@isocpp.org> <029d244a-cc53-40de-9c2f-59b1bc776c1b@isocpp.org> <481b4d44-74e0-4cd3-8141-62d35dea8350@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5076_330578662.1503944043493" X-Trace: blaine.gmane.org 1503944061 24376 195.159.176.226 (28 Aug 2017 18:14:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Aug 2017 18:14:21 +0000 (UTC) Cc: rmn100@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCNP5RVE2QIBB3F2SHGQKGQEOFYP2JI@isocpp.org Mon Aug 28 20:14:15 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f200.google.com ([209.85.161.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dmOXu-000575-CH for gclcip-std-proposals@m.gmane.org; Mon, 28 Aug 2017 20:13:58 +0200 Original-Received: by mail-yw0-f200.google.com with SMTP id b64sf4920288ywh.19 for ; Mon, 28 Aug 2017 11:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=MtpcKxUZE1b1cDcb5rVBzFrSv7/XDwOUJRKg7JP0ynY=; b=oOX1bdmvEnkp16votRXlsrWunxeKzm+dDBzIMHo+lGlyO1syOhQ3hIaIogBAcNvFEQ LGF/MtREethypUjDXowfu1umEEnR4VS2OJ65IOO2V2OkU/a0YIoxryygb8lEdypIm0z4 tWiBu1M2XpAW6Rm1XRr6unW8EM05rTMR7ahamo9gy5Bik37bIWWzEVaMUTMzDAnNrW/n okZ1A1s83UO9dIqO2kRDiDFubW4W5zq4jz5shRCfnKPOo3oJCWYK2iRXP/Ylf+EC9hGY EmwgOkOQvjs2kL8wtd9EMSdRRcRlNhkfdbpNCvOpQYe1m6OxqrKYfmCbRYzlsZSgOvJR iMdA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=MtpcKxUZE1b1cDcb5rVBzFrSv7/XDwOUJRKg7JP0ynY=; b=OQOJh98XEZxnO9ZwANVHRIS2aQeYdUNncWwznzjTi0YWU4gusyH5K98MT7jPogxC6Y XNHRAdlLedijkNom5FwnH6ZkjmAmPHLZ4pEfS9Z2FhbztFv3kigKO2zTBFMnMcT9fRiy 9Q4EhsVwgsQRIWa/bjvUDtiaUZ6njQTLju7pYdIfUWXeMShH8wgnEtGRf1Xyx61ubOjU UkV1EPLF6DCCOWEFDxB5CBdwuxdB1Yne01ui01Hlz1UjXgdFrufBoruMzaGi++tJ2zuu iugKf3WZDUskJDT+rwir48OG5kP02c8C6O3ZV9ubHMO0tX3W8bk43KquzAi5Ub7WyvGv EUvA== 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:cc: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=MtpcKxUZE1b1cDcb5rVBzFrSv7/XDwOUJRKg7JP0ynY=; b=Pio80qz7DOVYVxuAKm1AUxGYhvOmdTsHo3kZrMupHHLjlQQ8ngf6/jwLqg/77dBLd/ 2jzEuJda4yQBfISzasV04BNg+loabzfAILiXEjIbBqXoigzP0chBJayxXRCinHjxTNwR Yt/ROtQZ5hsBGLUJHXwGSwV8GqT/s2JVTjwd2/CKBklWohiYQvSbU2PwCKXk/7gJR8cB EPJjlLUm5u9RSAwDrKW9d8gTwpBkiIVrTTCTsUlNSQqB3hrtzwY/JGFHFQ1S/O7N9Zcv 6Wm/9MUYS4HlPqldRQlcgq5R2W7F2v9qQ8fYoLNYkUCE2AxP3Q7UrXX4fORCf030sgxr aEbg== X-Gm-Message-State: AHYfb5iDCdYQLF1Gj6+fzCjSKegfRV/ri9JRliEI7wUZYpH8K7Lf3fUE ycKlWq5Dt7po16pT X-Received: by 10.13.223.78 with SMTP id i75mr966602ywe.231.1503944045020; Mon, 28 Aug 2017 11:14:05 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.52.132 with SMTP id b126ls706089ioa.41.gmail; Mon, 28 Aug 2017 11:14:04 -0700 (PDT) X-Received: by 10.31.155.132 with SMTP id d126mr13664vke.17.1503944043936; Mon, 28 Aug 2017 11:14:03 -0700 (PDT) In-Reply-To: X-Original-Sender: rmn100@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:34181 Archived-At: ------=_Part_5076_330578662.1503944043493 Content-Type: multipart/alternative; boundary="----=_Part_5077_124583835.1503944043494" ------=_Part_5077_124583835.1503944043494 Content-Type: text/plain; charset="UTF-8" @T. C, The is_decomposable trait has the same potential ODR issues as std::iterator_traits. But in retrospect, it's not critical to the proposal of adding structured bindings to lambdas. So maybe it's something that I can just entirely leave out, and suggest addition later if this is a big issue. On Monday, 28 August 2017 09:44:47 UTC-7, Curious wrote: > > You are right. This makes me wonder. Are structured bindings not prone > to the same problems? The structured bindings decomposition checks to see > if tuple_size<> is a complete type first, and then go on to check if the > class can be decomposed via it's public members. For example > > class Something { > public: > int a; > }; > > namespace std { > template <> > class tuple_size; > } // namespace std > > template > void foo(SomethingType something) { > auto [one] = something; > static_cast(one); > } > > void bar(Something something) { > foo(something); > } > > /** > * Define the tuple shenanigans > */ > namespace std { > template <> > class tuple_size : std::integral_constant {}; > template > class tuple_element { > using type = int; > } > template > int get(Something something) { > std::cout << "get(Something)" << std::endl; > return something.a; > } > } // namespace std > > void baz(Something something) { > // now expect logging > foo(something); > } > > Although I suspect the above isn't an ODR problem because the bindings > aren't involved in the template instantiation process. Although it might > be surprising to the user. > > I wonder why a simpler approach wasn't taken, why check for tuple_size<> > to be a complete type rather than checking for the existence of a static > constexpr value or a std::integral_constant<> typedef within the class? > This can now be a possible change, instead of allowing tuple_size<> to be > specialized everywhere. Make classes that want to pretend to be a tuple > have a member typedef or a static constexpr and make tuple_size<> use that > typedef in the general case, and don't leave the type undefined (I suspect > this will break a lot of code, if people are checking to see if > tuple_size<> is a complete type). For example > > class TupleLike { > public: > using tuple_size_type = std::integral_constant; > private: > std::tuple a; > }; > > This is much simpler and is not prone to ODR issues. And now structured > bindings can check for the existence of and inspect the tuple_size_type > alias within the class. > > And then in the general case tuple_size<> can be defined like > > namespace std { > template > class tuple_size { > static constexpr const auto value = T::tuple_size_type::value; > }; > > } // namespace std > > The second simpler solution to the is_decomposable problem is to not use > the trait at all, and just let the lambda translate to an unconstrained > template function in an anonymous class. > > Also, to illustrate my question about extent of the check, what should the >> following code do? (This is basically GB 20's motivating example.) >> > > Shouldn't this cause a hard error? std::tuple_size is defined, and when > the code tries to use it, it finds out that the specialization is just > incorrectly defined. > -- 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/3509394f-e995-41d1-8fe0-3e7d8ecfe63e%40isocpp.org. ------=_Part_5077_124583835.1503944043494 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@T. C, The is_decomp= osable trait has the same potential ODR issues as std::iterator_traits. =C2=A0But in retrospect, it's not critical to the proposal of ad= ding structured bindings to lambdas. =C2=A0So maybe it's something that= I can just entirely leave out, and suggest addition later if this is a big= issue.

On Monday, 2= 8 August 2017 09:44:47 UTC-7, Curious wrote:
You are right. =C2=A0This makes me wonder. = =C2=A0Are structured bindings not prone to the same problems? =C2=A0The str= uctured bindings decomposition checks to see if tuple_size<> is a complete type first, and then go = on to check if the class can be decomposed via it's public members. =C2= =A0For example

<= span style=3D"color:#008">class Something {
<= span style=3D"color:#008">public:<= span style=3D"color:#000">
=C2=A0 =C2=A0 int a;
}= ;

namespace std {
template <>
class tuple_size<Something>;
<= /span>} // namespace std
=C2=A0 =C2=A0
template<= span style=3D"color:#000"> <typename <= span style=3D"color:#606">SomethingType&g= t;
v= oid foo= (SomethingType something) {
=C2=A0 =C2=A0 auto [one] =3D something;
=C2=A0 =C2=A0 static_= cast<void>(one);
}

void bar(Something something) {
=C2=A0 =C2=A0 foo(<= span style=3D"color:#000">something);
}

/**=C2=A0* Define the tuple shenanigans=C2=A0*/
namespace std {
template <>
class tuple_size= <Something<= /span>> : std::integral_c= onstant<int, 1>= {};
templa= te <= std::size_t In= dex>=
class tuple_element<Index, Something> {
=C2=A0 =C2=A0 using type =3D int;<= span style=3D"color:#000">
}
template <= std::size_t Index>
int get(Something someth= ing) {
=C2= =A0 =C2=A0 std::cout << "get(Something)&quo= t; <= < std::endl= ;
=C2=A0 =C2=A0 return something.a;
}
} // namespace std

void baz(Something something) {
=C2=A0 =C2=A0 // now expect logging
=C2=A0 = =C2=A0 foo(something);
}

Although I suspect = the above isn't an ODR problem because the bindings aren't involved= in the template instantiation process. =C2=A0Although it might be surprisi= ng to the user. =C2=A0

I wonder why a simpler appr= oach wasn't taken, why check for tuple_size<> to be a complete ty= pe rather than checking for the existence of a static constexpr value or a = std::integral_constant<> typedef within the class? =C2=A0This can now= be a possible change, instead of allowing tuple_size<> to be special= ized everywhere. =C2=A0Make classes that want to pretend to be a tuple have= a member typedef or a static constexpr and make tuple_size<> use tha= t typedef in the general case, and don't leave the type undefined (I su= spect this will break a lot of code, if people are checking to see if tuple= _size<> is a complete type). =C2=A0For example

class TupleLike {=
public: =C2=A0=C2=A0 =C2=A0 using tuple_size_type =3D<= span style=3D"color:#000"> std::integral_constant<int, 2>;
<= /span>private:=
=C2=A0 =C2=A0 std::tuple<int, int> a;
};

This is much simpler and is not prone to ODR issues. =C2= =A0And now structured bindings can check for the existence of and inspect t= he tuple_size_type alias withi= n the class. =C2=A0

And then in the general case <= font face=3D"courier new, monospace">tuple_size<> can be defin= ed like=C2=A0

<= span style=3D"color:#008">namespace std <= /span>{
template <= /span><type= name T&= gt;
= class tuple_size {
=C2=A0static constexpr const auto value =3D T::tuple_size_type::value;
};

} <= span style=3D"color:#800">// namespace std

The second simpler solution to the = is_decomposable problem is to = not use the trait at all, and just let the lambda translate to an unconstra= ined template function in an anonymous class.

Also, to illustrate my= question about extent of the check, what should the following code do? (Th= is is basically GB 20's motivating example.)

Shouldn't this cause a hard error? =C2=A0std::tuple_size is defined, and when the= code tries to use it, it finds out that the specialization is just incorre= ctly defined.

--
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/3509394f-e995-41d1-8fe0-3e7d8ecfe63e= %40isocpp.org.
------=_Part_5077_124583835.1503944043494-- ------=_Part_5076_330578662.1503944043493-- .