220 41272 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: constexpr also in switch() and even in for(). Date: Fri, 14 Dec 2018 16:24:50 +0000 Lines: 185 Approved: news@gmane.org Message-ID: References: <18750262-f0ab-4330-ab08-29004735c6bb@isocpp.org> <4fe7ab83-be8f-4f62-a1a4-72b39fb540d3@isocpp.org> <564ef691-3176-47f9-bf98-c5917c03b3d8@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000080dbb8057cfddf11" X-Trace: blaine.gmane.org 1544804578 20466 195.159.176.226 (14 Dec 2018 16:22:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Dec 2018 16:22:58 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBXVSZ7QAKGQE46MGJZQ@isocpp.org Fri Dec 14 17:22:54 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io1-f70.google.com ([209.85.166.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gXqEn-0005CL-Kk for gclcip-std-proposals@m.gmane.org; Fri, 14 Dec 2018 17:22:53 +0100 Original-Received: by mail-io1-f70.google.com with SMTP id a6sf5159194iok.0 for ; Fri, 14 Dec 2018 08:25:04 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1544804704; cv=pass; d=google.com; s=arc-20160816; b=ViPJHENIfb9apmnVNFphKGZSWMynhgaxfCzXI0QZ7z6EYGlIWZ9fUruNly3cigJw5E zxCgqpSWF3N2S4s5i8rX4royrqs0TIcIY/jEPKi4Uz8IJ+IhKuY8Hsh9ARff8dALiLAC 8M3iSb1ZY1PzY4nbbX8f0dz18paOMbF8gVmM/I+hGp+aNmUM36cMTlZa21KJX2JWbw9Y xmAEcq+mpnLwsScj+x7jzMIxPzukYgTU6lGWVmwGbJWWOvewanKaExbyx4hG+jxKnvb8 b2cpog1/sCsu//nt/oFZPLAQokZ9fYHY7zxcEe+unHWilfwJ/gVba0wazU7OwB1IQ5jV y+eQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:dkim-signature; bh=Zhyc/PHxq9NJeD1k05YtmbLeUR72QWHkOQ9iRv2mRQM=; b=vYeuVMLA9RxMz8nxpvHWgOVu3lXxJ/5I9SfLwNlgiXqPDhDkh0bESRG40hGDV9e9cv fiQSIMXfs7oMDhCs6z0fBGvLH4hWFvoCKjkDvO2Y76mwj2grAKNqA+8yaYJUfu6Nvbmy BImmQ7XTjDu72ycFFn8h3zVPZIYoGnUTOQxpKrQh4i53Z9bl2Sj2rBB3QZ/TvqmZFe06 Gh4GlzPZztChMarM5Z8wX0dEb0HPZYpzpRQTcaiNLQqUxb25798jwVSuQ+mq1hjz8lud Dw78PyRiycyrlm1N4lKgBf7gfOjZxw6/0eILBfWsE0b40vfw78RnBTT1IdT49/7s25YN RLZA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SyinPHmz; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Zhyc/PHxq9NJeD1k05YtmbLeUR72QWHkOQ9iRv2mRQM=; b=m9Qf4U5x2Vi31Oa6n0sytCPeVBclkh5lDH0Njo2lC7Z90KuhSsvkZiKaJGUVr9mnmX yrxqyYXXZt/AZy/AEMeMzw/4nVArkLTOwFhkb2Q5K4W3IMaQzqP3NX1ctfU7+STbASDP TW5Y86vZEk6Z8TW+nkbBLeqrnQXHpzk8Cfg6iZMbOLg/PSMbwoRP/2jaxdi72EXLoVME TBKc3TiXsIfX65NdEVY6meTD91/L70X9tYocS/mJk/olqWcyQmsYcIRWrBYp63fFHm6g VQQGsX0rJHyMrXcF9tRG3lswzs/c/xaGGGROjuorN6xKv9+o3/SmMsv0Gjpr6UzSDbo/ 0nuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to: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=Zhyc/PHxq9NJeD1k05YtmbLeUR72QWHkOQ9iRv2mRQM=; b=ULhlZw4D+FF68Av7JXDcQHsGsDBSaO7jv0ZMMtjrf8b1Da4/H2gEJlj1LZwg9kvyMe of/rcmYNV036XhT/bFbcpuni5yeWkhavo07O+2mRrTktzapFF/3mioT9vFKJppgNzLf5 9Bies/Wt/y1S5NXscyhuWxkTtQJ7Q5qA9mgGtd0jDaQ6wJizj8Hn5oR8oVXiyPuOaDlQ 3f+Dp0SI3d767e1j8esSTpNqLmXhgFtp2LcZIn63ZugZk7qn5FblxIIo7KAKO7JNTdh4 yAY1SjrFDL/+jB0cat4eWDB9stfJkeqpDpaSNPgX6Hhh6ozu2PnOl6wOKtK2VJp6Yflh SQ7A== X-Gm-Message-State: AA+aEWYZKFHBDfu9W1igP5I9oeCjwhF0CU3NVfiWVxQkBomxYgSnr6Mn lqXrOxwpUnHfrloILDwpPnU9bw== X-Google-Smtp-Source: AFSGD/XNxDhdGAcCn2Elkx7PN0ruhcEKfw9I8VerXdePi02wPOTFuYjaHQW0g+wVlJCPYgSS0qCCtw== X-Received: by 2002:a5e:c80b:: with SMTP id y11mr2914072iol.20.1544804704114; Fri, 14 Dec 2018 08:25:04 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a24:224d:: with SMTP id o74ls426938ito.4.gmail; Fri, 14 Dec 2018 08:25:02 -0800 (PST) X-Received: by 2002:a24:1a90:: with SMTP id 138mr3556282iti.171.1544804702419; Fri, 14 Dec 2018 08:25:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544804702; cv=none; d=google.com; s=arc-20160816; b=uQZ75RAJoSL8Bqo3e1eweOeI+Oq5CffA1PCxLbpxRDXbANqk0A2gdQbIrgeKrd+UL/ oilLZ3zmkilXZvEn3NE1Lt0ns0C4WgJwkkNC6CTXc/YtxdgIQJ6BKacrVeHT0z5kmhZr CUcsHHJZtMyzYC35RfLmMY+bZadbCHgUUQ/Qkbs3KQHN/K9HkxL/e3rR64cSW4fnOtXr Nwi1sOpRpmp/BFLnU74fILeI96Ak48bLdOG0Fl3emn6PSy5dgA0OLBUYXahkUqMAUBLQ 9KVKK3JoVzgDGlokYuaBufEcAQbyg9BP4ETRWsf5KgHFPwozrgvpCbehsFSCxrfMcZtd iXHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=eW4IQgldF77jJeadlUxnaRUxQXAPrSypJIJ1dZc8uVE=; b=iFH2fk3imTdJiRURC1ar6oJLZcypgacNYdpWFZp/M8IS62iRcs1WBgkQqN50UAy/D7 GuYQQVcuoAf/VtlzLTvWira6Fv3304riwthJpS6deLjs7T3cGGjMPbq9YF6mJjE3WAB6 Quevp56xflA+pT2RLVrn6Pq1EidbmCsiXSmVFiSRcGjX/5CTMKOUtZsAO8CwdptKllZz +mX97RSy5KtK/GI8nYSNKdTQwryAemRyvvAgdA7ic1yP6gAAvY52uCh5WW5d7vg+b7qH SO3BhBEQ40C9HxWBncPIm2XjJtm+BTV+EWXSxNTI0rXQFWI4TyBeh9AHgdDV8lDR+hDb 2zEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SyinPHmz; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id u16sor1402142ioc.24.2018.12.14.08.25.02 for (Google Transport Security); Fri, 14 Dec 2018 08:25:02 -0800 (PST) Received-SPF: pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a02:3ec3:: with SMTP id s186mr3355838jas.32.1544804701885; Fri, 14 Dec 2018 08:25:01 -0800 (PST) In-Reply-To: X-Original-Sender: jake.arkinstall@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SyinPHmz; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:41272 Archived-At: --00000000000080dbb8057cfddf11 Content-Type: text/plain; charset="UTF-8" On Fri, 14 Dec 2018, 16:06 Richard Hodges I agree that this makes a valid and compelling use case for the >> for-statement. However, in this particular case I believe the problem could >> also be addressed with a library function able to iterate on the various >> elements of a tuple. For example: >> >> /*std::*/for_each_tuple_element(disp, [which](size_t i, auto f) >> { >> if (i == which) f(); >> }); >> >> I believe such a function could be written using an approach similar to >> one used in your link and might be worth considering for standardization. >> > > Such a function can be implemented by wrapping an expansion of std::invoke > in a lambda called by std::apply. The problems are: > > 1. It does not detect the no-match case. > 2. Return types have to be the same/compatible > 3. ** It's not easy to read ** > 4. Less control flow - no "break". > Compile time stuff needs to be childs play to be useful, and c++ is almost > there. > Agreed. I use tuples heavily and I get an unreasonable amount of satisfaction whenever I implement something that should have been trivial. It should be easier. The standard library currently provides enough tuple utilities to be able to cut the code for a trivial operation (e.g. A map from a tuple to another) from 100 lines to 50, but we're really missing out on some nice high level features. The route that the library is going down is never going to be easily usable by your everyday C++ dev, and that's simply because the language isn't built for it at the moment. A compile time for loop is something I strongly support. I do not support claims that there will be trouble if a type in the tuple doesn't support an attempted operation - the loop unrolls and should act like any code that was written sequentially instead (plus jump labels). If it causes an error, it causes an error. It would be nice if we can have a type that represents a tuple of types that all share a common concept. > There's no reason why compile time meta programs should look any different > to runtime programs. > Again, I agree. -- 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/CAC%2B0CCO64OLWVF6eSwXESWCXf0vrjv5Z2zeCX3hRLMsc%2B-C3jg%40mail.gmail.com. --00000000000080dbb8057cfddf11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Fri, 14 Dec 2018, 16:06 Richard Hodges <hodges.r@gmail.com wrote:
I agree that this makes a valid and compell= ing use case for the for-statement. However, in this particular case I beli= eve the problem could also be addressed with a library function able to ite= rate on the various elements of a tuple. For example:

<= div>
=C2=A0 /*std::*/for_each_tuple_eleme= nt(disp, [which](size_t i, auto<= /span> f)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 if (i =3D=3D= which) f();
=C2=A0 =C2=A0 });

I believe such a function could be written using an approach similar to o= ne used in your link and might be worth considering for standardization.

Such a function can be implemented by wrapping an expansion of = std::invoke in a lambda called by std::apply. The problems are:

1. It does not detect the no-match = case.
2. Return types have to be the same/compatible= =C2=A0
3. ** It's not easy to read **
4. Less control flow - no "break= ".

Compile time stuff needs to be childs play to be = useful, and c++ is almost there.

Agreed. I use tuples heavily and I get an unreasonable amount of satis= faction whenever I implement something that should have been trivial. It sh= ould be easier. The standard library currently provides enough tuple utilit= ies to be able to cut the code for a trivial operation (e.g. A map from a t= uple to another) from 100 lines to 50, but we're really missing out on = some nice high level features.

The route that the library is going down is never going to be easily= usable by your everyday C++ dev, and that's simply because the languag= e isn't built for it at the moment. A compile time for loop is somethin= g I strongly support.

I = do not support claims that there will be trouble if a type in the tuple doe= sn't support an attempted operation - the loop unrolls and should act l= ike any code that was written sequentially instead (plus jump labels). If i= t causes an error, it causes an error. It would be nice if we can have a ty= pe that represents a tuple of types that all share a common concept.
<= div dir=3D"auto">

There's no reason why compile time meta programs should loo= k any different to runtime programs.

Again, I agree.

--
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/CAC%2B0CCO64O= LWVF6eSwXESWCXf0vrjv5Z2zeCX3hRLMsc%2B-C3jg%40mail.gmail.com.
--00000000000080dbb8057cfddf11-- .