220 31511 article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Enhanced fold expressions Date: Wed, 8 Mar 2017 14:58:17 -0800 (PST) Lines: 303 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2273_1087352596.1489013897864" X-Trace: blaine.gmane.org 1489013905 23691 195.159.176.226 (8 Mar 2017 22:58:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 8 Mar 2017 22:58:25 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIIVGMCYYCRUBEKIVTFQ@isocpp.org Wed Mar 08 23:58:16 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 1clkX7-00056V-Ou for gclcip-std-proposals@m.gmane.org; Wed, 08 Mar 2017 23:58:14 +0100 Original-Received: by mail-qk0-f200.google.com with SMTP id n141sf111953483qke.1 for ; Wed, 08 Mar 2017 14:58:20 -0800 (PST) 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=+INumRQkM44TUWKk38unlkSelsxvksEoUlzD4syK1gA=; b=Uj2S/pvUO7ef0uZ+30w4SMtKLDWtgqjtgi1yesR7q4Bx/A1cjOZ0PS8lescWqQ71hC led4BYb8+OiFT2yfXMLlZuEP2XWDBKqaweldqcln1mkLPSp1wsbqyITWgqUbcHzUmjRs XMQ6Llzk3lZod/XFSJ6kEM2CbZXfvAd7Uapsb+DNJBKtOgiAN1/gfpcg4VjASmQDT7UY FCl1M9lUqyDOlVY9VuRDlKYRFxVFe03772kxBVc+XeOUcSH4CbEjKRNetVZwZd9vc39C XP0Z4PpJNTUSe3FxxlQPc+AD6gpV6O1g/VoRFApeQI/hV3HZxB3fKQNe3l2rqKlhOChJ mO9g== 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=+INumRQkM44TUWKk38unlkSelsxvksEoUlzD4syK1gA=; b=h0tH1Tr4Yc3oZQ79kIxTui/P3YJ3vGOe1cRUkiFLq8yXyKy6piABHNsEFAbIYWItYV TEmxLj5JnWvGZ+sfoEqa0edD/zDh7HxT3Q18s1Glcsv9kEwyJ6Y7FVcKCjgdKX36My2M AW/jjSWf6RYxkakv+xnHMnhk7VvMMaPWb5sYp9lfxR3IidOvgCXWAExNhaoltpWirCZA N/1rPUHU2Z1Mq+n8B9xrI9TdrIK3rQpOdpGF8V62c3v1hMu+iikm2uMq8oeUctJBT3uB OENAjOUh9Myl22pF0tq/XeC1A2R8uDnNFx2oQ9EHatBDnqc7LyWwbmaL3o7DzE49cjia LJBQ== 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=+INumRQkM44TUWKk38unlkSelsxvksEoUlzD4syK1gA=; b=lN714+FcqMgWiiZTHYrZw0X/OoIvTKkyCQ1LBccHUNvFkuN0umDtOJRt9uKrRw2QSU 6wyPyUYQpdWrQe26db3H0D9pTNMghcZR3T1neJdPpaOCJvowM+C8GJRFjCueealk6wr/ UedB6L+vLUX1SzMKQph1HQMrPGZ5RSmE9WZKCSGbHOq3c6BoFs1GQqDQVEi5lNOecc/e 5ZiHzWvcb+0P9Ze1tlQq/5sQoMThTin1pC2tcdkzq5xc/DPsuytjzMf8usuyzrKhtlDq CTY5QHfMUEIbuQuTC1Nsi78Dl9vcFkKAkbOY4lmfvdvMcN762HA0sR3N9WniLzVUbkb7 cKrA== X-Gm-Message-State: AMke39lFw361osScEDlYHFstSqkG/CU54XdN/vGniUyFh9R9Tsd3YUpLpEVY264kitPSWA== X-Received: by 10.129.71.9 with SMTP id u9mr3727440ywa.142.1489013899539; Wed, 08 Mar 2017 14:58:19 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.47.173 with SMTP id r42ls443401otb.26.gmail; Wed, 08 Mar 2017 14:58:18 -0800 (PST) X-Received: by 10.157.32.3 with SMTP id n3mr1324541ota.1.1489013898679; Wed, 08 Mar 2017 14:58:18 -0800 (PST) In-Reply-To: X-Original-Sender: arthur.j.odwyer@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:31511 Archived-At: ------=_Part_2273_1087352596.1489013897864 Content-Type: multipart/alternative; boundary="----=_Part_2274_525504152.1489013897865" ------=_Part_2274_525504152.1489013897865 Content-Type: text/plain; charset=UTF-8 On Wednesday, March 8, 2017 at 11:11:27 AM UTC-8, Roman Orlov wrote: [TLDR: folding over arbitrary binary functions] > > I suggest to extend the meaning of binary operator in fold expression. *Operator > is a function*, so any *constexpr binary function* could be used in fold > expression. > I've invented a little hack to proof the idea > (Minor point: constexpr is completely irrelevant to your use-case. You should drop the mention of a constexpr requirement.) This hack is not new. See e.g. https://ngathanasiou.wordpress.com/2015/12/15/182/ http://stackoverflow.com/a/42587567/1424877 > template > constexpr T min(std::integer_sequence) > { > return (... << dummy_int(Args)); // explicitly convert to dummy_int > } > Using my version of the hack, you would write template constexpr T max(std::integer_sequence) { auto mmax = make_named_operator([](auto&& a, auto&& b){ return std::max( a,b); }); return (... + mmax(Args)); } Nick Athanasiou's original blog post takes the more functional-programming approach: that what you should really write is return foldl([](auto&& a, auto&& b){ return std::max(a,b); }, Args...); The code would be simpler if I can write it like this > > template > constexpr T max(std::integer_sequence) > { > return (... std::max Args); > } > Agreed that that might look simpler (and you could add a code comment with that syntax if you think it'd help the reader); but I don't see how you expect the compiler to figure out what you mean by that syntax, unambiguously. For example, what is return (... std::max (Args)); return (... std::max Args); return (... func_ptr Args); return (... (*func_ptr) Args); return (... func_ptr*Args); return (... (*Args) Args); Any time you take a piece of the grammar that currently accepts a closed set of operators and propose changing it to accept an open set of expressions, that's a red flag; or at least an indication that you need to think really hard about whether there might be any corner cases. FYI, Barry Revzin's P0573R0 (which I am generally against) mentions (but does not propose) the syntax []std::max as a shortcut way of writing [](auto&&... args) -> decltype(auto) { return std::max(args...); }. If we had that, not only would the two alternatives presented above get a lot shorter, but you wouldn't have to worry quite so much about the fact that the identifier std::max by itself doesn't denote any particular *entity* (but rather just an overload set of a bunch of otherwise unrelated entities). You could design your syntax to work cleanly with []foo by design. my $.02, Arthur -- 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/dd6502e6-274b-4de4-b31f-1fe9783456eb%40isocpp.org. ------=_Part_2274_525504152.1489013897865 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, March 8, 2017 at 11:11:27 AM UTC-8, Roman Or= lov wrote:
[TLDR: folding over arbitrary binary functions]=C2=A0
I suggest to ex= tend the meaning of binary operator in fold expression. Operator is a fu= nction, so any constexpr binary function could be used in fold e= xpression.
I've invented a little hack to proof the idea

(Minor point: constexpr is complete= ly irrelevant to your use-case. You should drop the mention of a constexpr = requirement.)

This hack is not new. See e.g.
=
=C2=A0
template<typename T, T... Args>
constexpr T min(std= ::integer_sequ= ence<T, Args...>= ;)
{=
=C2=A0 =C2=A0 return (... << dummy_int(Args)); // explicitly convert to dummy_int
}
<= /div>

Using my version of the hack, you would write
<= div>
template<typename T, T... = Args>
<= span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr T max(std::integer_sequence<T, Args...&g= t;)
{
=C2=A0 =C2=A0 auto mmax =3D make_named_operator([](auto&& a, auto&& b){ return std::max(a,b)= ; <= span style=3D"color: #660;" class=3D"styled-by-prettify">});
=C2=A0 =C2=A0 = return (... + mmax(Args)); }=
=

Nick Athanasiou's original blog = post takes the more functional-programming approach: that what you should r= eally write is

=C2= =A0 =C2=A0 return fo= ldl([](auto&& a, auto&& b){ r= eturn std<= /span>::max(a,b); },= Args...);
=


The code would be simpler if I can write it like thi= s

template<typename T, T... Args>
constexpr T max(std::integer_sequence<= /span><T, <= span style=3D"color:#606">Args...>)
{
=C2=A0 =C2=A0 return (... std::max Args);
}

Agreed that that might look simpler (and= you could add a code comment with that syntax if you think it'd help t= he reader); but I don't see how you expect the compiler to figure out w= hat you mean by that syntax, unambiguously. For example, what is

=C2=A0 =C2=A0 return (... std::max (Args));
= =C2=A0 =C2=A0 return (... std::max<int> Args);
=C2=A0 =C2= =A0 return (... func_ptr Args);
=C2=A0 =C2=A0 return (... (*func_= ptr) Args);
=C2=A0 =C2=A0 return (... func_ptr*Args);
=C2=A0 =C2=A0 return (... (*Args) Args);

Any time you take a piece of the grammar that currently accepts a = closed set of operators and propose changing it to accept an open set of ex= pressions, that's a red flag; or at least an indication that you need t= o think really hard about whether there might be any corner cases.

FYI, Barry Revzin's P0573R0 (which I am gene= rally against) mentions (but does not propose) the syntax []std::max as a shortcut way of writing [](auto&&... args) -> decltype(au= to) { return std::max(args...); }. If we had that, not only would th= e two alternatives presented above get a lot shorter, but you wouldn't = have to worry quite so much about the fact that the identifier std::max by itself doesn't denote an= y particular entity=C2=A0(but rather just an overload set of a bunch= of otherwise unrelated entities). You could design your syntax to work cle= anly with []foo by design.

my $.02,
Arthur

--
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/dd6502e6-274b-4de4-b31f-1fe9783456eb= %40isocpp.org.
------=_Part_2274_525504152.1489013897865-- ------=_Part_2273_1087352596.1489013897864-- .