220 34235 article Path: news.gmane.org!.POSTED!not-for-mail From: Ricardo Fabiano de Andrade Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: constexpr only functions: arbitrary literal types for non-type, constexpr arguments, is_constexpr... Date: Thu, 31 Aug 2017 15:17:37 -0500 Lines: 1082 Approved: news@gmane.org Message-ID: References: <17e156a0-0368-4ec0-a087-e8b4bc8d9f62@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c1fb964f4ccea05581255cf" X-Trace: blaine.gmane.org 1504210678 9717 195.159.176.226 (31 Aug 2017 20:17:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 31 Aug 2017 20:17:58 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCJN7V7TRQMBBY65UHGQKGQEONIGAYQ@isocpp.org Thu Aug 31 22:17:49 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f197.google.com ([209.85.161.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dnVuB-0001Jo-3J for gclcip-std-proposals@m.gmane.org; Thu, 31 Aug 2017 22:17:36 +0200 Original-Received: by mail-yw0-f197.google.com with SMTP id l2sf1674914ywe.23 for ; Thu, 31 Aug 2017 13:17:41 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1504210661; cv=pass; d=google.com; s=arc-20160816; b=buWe71sjxNLlwfzsE7MZmS5f1piXdxy1VgRLUoOxvm3ItdIHderLEYxLpwb2J4DNy5 r91s8yaZVW4dc34QlSBYOoY/GtmloK0oF3aHwZgg5JGEU4uGR8Fh5hBHN3W2JJUZuvKB F22RbBnGXyDx79kzDN3UD3gmEd78wuZF2Of/lYgp1UXPxnpfR8gFKKYjp1Gdky/dxuOh RBPj8r4PQjSMjkQJ2hzAJoVq/SCxT/X0ndB+C5LqmM13Ws/iIueDml2gN9D9R6weozHr F7AVZBRKDX/KfY9EltYb9+oSw8IlEq1aNkaRLl02c/QTohlLtcsB1yV1IJIR5O3Jt+9u 4PvQ== 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:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=dPx7nChmcOEDqCXS1IICc8M4UGnNKuveh0hvRTrMizk=; b=NutF0L8A0vPWTc8ymqgsjdZpVh14D0n9IIq9c8aF0HvHn76sFBshIqhpKR4tEr+Pba G+YiMW9TFtR5USJBjgq27F1DW4qHGQ5v/AEiettOA2vVnUtXkSCBrdfMFA4VGHLWJkXS pAF2cnuw13hROMmpaAdCpB2QVAp06AgqElr2Xb6d3K3FDS+r7rN2IXBWt6rlBA7yjb7r mwOttly4Y1r20uX/reldyoYmaHdBHvJ4LJxeycpYQRlaFNos78nmZ2l/6QwoIz+HT1u0 fJ/QYIVhBjALgCgxl2/QL0HLE1ocaf8H6Pa7Oh/FKrx2qFePeZPKWPbux4oyO2+2F1Lq mFIw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=m54aefTk; spf=pass (google.com: domain of ricardofabianodeandrade@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=ricardofabianodeandrade@gmail.com; dmarc=pass (p=NONE sp=NONE 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:in-reply-to:references: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=dPx7nChmcOEDqCXS1IICc8M4UGnNKuveh0hvRTrMizk=; b=BJcOvtSZw7FiY94Cy4wWPGRCgMVgevS6OehUirhRI2EPUA80GPKLON/erLkf+dd9hp y0alAz//Kpsb5ib4q+Jt3MvUZl7pwGFArzo7QndGQo3LQKbaNfmJXEJf6RlZ4IhV8z64 cyYOn+mfNY1QnNEgAtsF+PHwRZx8J6RGggUwuT6D6hc1UE3dqhihWL4rWXLgMCnZTlFM mosKTbBpfcesw8+o9zI4I4mVFrthCPUJ2Tp6Pj4dVi6p4mwPEWb555YhKuN0UL0zxT/K MhWBoCEPROp5VizvJWFczx5lenl1EAOc5Fhp+nFFB2p9Nywz/aM/aKF7oqfDYdijyoIy dWGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references: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=dPx7nChmcOEDqCXS1IICc8M4UGnNKuveh0hvRTrMizk=; b=laglGKznfadmh0WYkXJWDUos7YLnXehiRBJbtU0EuRedsw/PrUPY/DLYDbFSyYsiN3 gcwhKZcAD0w0yWZG8GITYn9Gx9pFQoW/gviKEX+9gdwEXm8WT4OyVbiW3THA9gAfc/9K rf6SCQK1Q0bCbVyKbDlvpkZhx97BQhPxYVQ7vThycgaD81VhjtnL+PysljxMa/WAFJ6f A5c9Z0sHNG7WxvFUU0jRphYwNW6A4LIJPXX4bCdDkIYf6anfogHvE44C59yBIITPaxxD qYbhDfq3P+4/mi+YRuYHjyirztLKx18AhvwLx+eriIRE94QdNvEPkwit6KbX1IiLcXlX w0ow== X-Gm-Message-State: AHYfb5ha9aBEMUTtN9+Ya5paRD1fajPPtDmup64szVNXcKeQUyW34nbT Apuo5/jIWG3dBbYu X-Google-Smtp-Source: ADKCNb6YoawqzqhdCII2nfnvfbLoFbDL0relJjXzrTi/h2472SKOCLdRSHXslHVAMKSJc878ZQ4LYg== X-Received: by 10.129.99.2 with SMTP id x2mr4006228ywb.172.1504210661121; Thu, 31 Aug 2017 13:17:41 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.14.73 with SMTP id 70ls279380ioo.45.gmail; Thu, 31 Aug 2017 13:17:39 -0700 (PDT) X-Received: by 10.107.46.96 with SMTP id i93mr6609812ioo.161.1504210659182; Thu, 31 Aug 2017 13:17:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1504210659; cv=none; d=google.com; s=arc-20160816; b=byFG+5zMtYOYzrwWgZRX0dqOdDY70xBEVw+c104zb7zyiJ4Dsu0W9zCb/RG2R8qkLn micGNixajysF7kFNGVuIkQGakHGICvxjzP0Ne7rGlWyF1cvBNI6E2cAWcFW8Z7ZnIloc JEHXFEeriojdWs5aprqtSavlBuehMOp2B10eUXgswZwZneLo8jqJd65Dv5PB9XPJUwvH PWVM+CncuAQgxeOJo6QOSgKREJxK1HuV/YXkfXyqdYhdSMvJLHGq+cBIJ8pG9f7mpy6U majJB2CNUnXOMHyGSooe6emcEKlOpwpWhIeoRHOG3xqnyx08wAYyz5dYFA3Nt0CfeF3t VFaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=GhgNwq2RexEAkFQItDVkMcEics86Y4AVB0hSsOcudn4=; b=yjIcFDyMHXaufTIAS2i1VEsujmh7+Thmk3J/tQgqika5W222EV35fUOYpz4aIq1ewW O+R0yyrFn/JI+PPGJW3SYhTxscxVHM/TWWH6r/IEWZNt5A9jezKE16C1C0WyjEFy+MGX FMYaoXn8kFGaUOlk+FtXgPd5nfJOZPin30vh6uE4wOIaGQNvjXLlJwx+RTzIJb93PxXl 6VvdP9cGnijBnXtJ73KfeBsWR2lwD+MUgHgyfRFrpMuKwjYkwbUX41bJMRGJGMQTuYnL wkOyz0hGDP7g0VyFjD/p/i8/7+c5HBbE6U9uRZlT7NfM5iIc8HD/67F8306xliHU60OR n8cg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=m54aefTk; spf=pass (google.com: domain of ricardofabianodeandrade@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=ricardofabianodeandrade@gmail.com; dmarc=pass (p=NONE sp=NONE 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 j82sor569154ite.98.2017.08.31.13.17.39 for (Google Transport Security); Thu, 31 Aug 2017 13:17:39 -0700 (PDT) Received-SPF: pass (google.com: domain of ricardofabianodeandrade@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.36.172.28 with SMTP id s28mr2045882ite.140.1504210658313; Thu, 31 Aug 2017 13:17:38 -0700 (PDT) Original-Received: by 10.107.13.14 with HTTP; Thu, 31 Aug 2017 13:17:37 -0700 (PDT) In-Reply-To: <17e156a0-0368-4ec0-a087-e8b4bc8d9f62@isocpp.org> X-Original-Sender: ricardofabianodeandrade@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=m54aefTk; spf=pass (google.com: domain of ricardofabianodeandrade@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=ricardofabianodeandrade@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:34235 Archived-At: --94eb2c1fb964f4ccea05581255cf Content-Type: text/plain; charset="UTF-8" Very interesting proposal. Looking forward to hearing additional feedback from others, I hope it moves forward. Simple syntax question: why not placing constexpr() next to where noexcept() is, at the end of the function declaration/definition? This alternative seems more consistent, even with lamba functions examples. On Thu, Aug 31, 2017 at 1:43 PM, Bastien Penavayre wrote: > Hi, > > So let me pressent the current state of affairs. > > There are a bunch of proposals floating around, that, I think, are > interesting but have issues implementation-wise or are a bit clunky. > *N3413* (arbitrary literal types for non-type) for instance requires that > a bunch of controversial questions to be answered to be accepted (mangling, > operator== or bitwise, ...). > Because of that this proposal will not come around any time soon. > At the same time demands to check or enforce constexpr-ness in functions > were made through the ideas of *forced constexpr arguments* and* > is_constexpr()*. > > - The first has the same issues as *N3413* as it requires said > constexpr arguments be integrated into the mangling of the function, making > this proposal syntax sugar to *N3413*. > > //this > template void func(); > //differs only through call syntax from this > void func(constexpr Literal l); > > //yet this would allow to get rid of atrocious code like this > template > constexpr auto func(std:integral_constant); //only uses I > > - The latter (*is_constexpr*) aims to allow a runtime or > compile-time specialization through a constexpr expression with a > variant value. It would requires long *if constexpr *blocks as, if > runtime specialization is required, we can assume that the runtime and > compile-time version will share very little code. It would also mean > that, despite the confirmation by the compiler that we are in constexpr > context with arguments being compile-time evaluated, we would still be > incapable to use those as such or would require that *if > constexp(is_constexpr()) *have side-effects (big no-no). > > constexpr auto func(int i) > { > if constexpr (is_constexpr()) > { > //i is still not usable as a constexpr > //long piece of code or call to other function that handles the > compile-time version > ... > } > else > { > //long piece of code or call to other function that handles the > runtime version > .... > } > } > > Now that the context has been presented here is my proposal with a > detailed and commented exemple. > My goal is to allow a big chunk of what the other proposal aimed to allow > without all their issues and in one proposal. > It is to allow constexpr-only specialization by borrowing the *noexcept* > syntax. > As the function may only be constexpr it will not have linkage and > therefor no mangling nor all the issues associated with it. > Now here is a *detailed exemple*. > > //compile-time only function > //it will never have linkage > //all its arguments are constexpr > //a non-constexpr expression usage in its definition will cause an error > instead of a fallback like normal constexpr > //is only called in an explicit constexpr context unlike normal constexpr > constexpr(true) auto func(Literal r); > > //runtime specialization of func > /*constexpr(false)*/ auto func(Literal r); //constexpr(false) is the > default for functions and methods > > //error redefinition of 'constexpr(false) void func(Literal)' > constexpr void func(); > > constexpr(true) auto func2(); > //allowed > //constexpr is ignored, retains inline side effect > constexpr auto func2(); > > constexpr auto func3(); > constexpr auto error_0 = func3(); > //constexpr specialization of 'func3' after instanciation > constexpr(true) auto func3(); > > //addresses demands for partially constexpr argument-list > constexpr(true) void partial_constexpr(int constant) > { > return [&](auto&&... runtime_args) constexpr /*this lambda has the > default constexpr behavior*/ { > //runtime code > //can use 'constant' as a constexpr here > }; > } > > int main() > { > constexpr auto r_0 = func(Literal{}); //constexpr(true) version called > auto r_1 = func(Literal{}); //constexpr(false) version called > > partial_constexpr(42/*compile-time args*/)(/*runtime args*/); > > auto r_2 = constexpr func(Literal{}); //also proposed unary constexpr > operator for explicit selection, error if the expression is not constexpr > //is equivalent to > auto r_3 = []() { constexpr auto __ret__ = func(Literal{}); return > __ret__; }(); > } > > //replacing of gnu's operator"" extension > constexpr(true) auto operator""_string_literal(const char *str, size_t len > ) > { > return [&](std::index_sequence&&) > { > return TemplateCharSeq{}; > }(std::make_index_sequence{}); > } > > //operator[] for std::tuple > template > struct tuple > { > ... > constexpr(true) auto& operator[](size_t i) const > { > static_assert(i < sizeof...(Args)); > return std::get(*this); > } > > constexpr(true) auto& operator[](size_t i) > { > static_assert(i < sizeof...(Args)); > return std::get(*this); > } > .... > }; > > template struct Select : Args... { using Args::operator > ()...; }; > template Select(Args&&...) -> Select; > > //for lambdas > void func_3() > { > constexpr auto f_0 = []() {}; //operator() is constexpr /*fallback on > runtime*/, no changes > constexpr auto f_1 = []() constexpr(false) {}; //operator() cannot be > called at compile-time > constexpr auto f_2 = []() constexpr(true) {}; //operator() can only be > called a compile-time and explicitly > > constexpr Select f_3 = { f_1, f_2 }; > > constexpr auto r_4 = f_3(); //f_2 > auto r_5 = f_3(); //f_1 > } > > Here is the summary: > > - extend constexpr specifier to allow it to take a constexpr explicit bool > (no a constexpr expression unless if there are good use-cases for it) where: > > - constexpr(false) is the default specifier of a function/method > - optional for functions/method. > - if specified with lambdas allows not-constexpr lambda as lambdas > are by default constexpr. > - constexpr(true) is a constexpr only function. > - no Assembly representation (no linkage nor mangling). > - all arguments are constexpr. > - error if non-constexpr expression is used (a constexpr fallback > to runtime because of an overflow for instance). > - only used in explicit constexpr context. > - cannot be called before its specialization if specialization or > else error. > - constexpr > - keeps all its properties and definition. > - will still trigger redefinition error if previous > constexpr(false) version previously defined. > - constexpr attribute ignored if previous constexpr(true) is > defined. > > - unary constexpr operator to request a constexpr expression explicitly: > auto t = constexpr expr; //might error if expr is no a constexpr > expression > > The reason why I believe in this proposal: > > - no new keyword. > - zero runtime impact. > - maintains backward compatibility. > - solves, at least partially, a lot of different proposals. > > Thanks in advance, > > Bastien Penavayre, > bastienPenava@gmail.com > > -- > 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/17e156a0-0368-4ec0- > a087-e8b4bc8d9f62%40isocpp.org > > . > -- 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/CA%2BfGSbMtnehJhDx3Bz_GfxsqyrK_ch5hes7aGZqnufrimtG%3DgQ%40mail.gmail.com. --94eb2c1fb964f4ccea05581255cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Very interesting proposal. Looking forward to hearing addi= tional feedback from others, I hope it moves forward.
Simple syntax que= stion: why not placing constexpr() next to where noexcept() is, at the end = of the function declaration/definition?
This alternative seems mo= re consistent, even with lamba functions examples.

On Thu, Aug 31, 2017 at 1:= 43 PM, Bastien Penavayre <swac31@gmail.com> wrote:
Hi,=C2=A0

= So let me pressent the current state of affairs.

T= here are a bunch of proposals floating around, that, I think, are interesti= ng but have issues implementation-wise or are a bit clunky.
N3413 (arbitrary literal types for non-type)=C2=A0for instance requires=C2=A0that a bunch of con= troversial questions to be answered to be accepted (mangling, operator=3D= =3D or bitwise, ...).
Because of that this proposal= will not come around any time soon.
At the same time demands to check or = enforce constexpr-ness in functions were made through the ideas of fo= rced constexpr arguments and is_constexpr().
  • =C2=A0 =C2=A0The first has the same issues as N3413<= /i> as it requires said constexpr arguments be integrated into the mang= ling of the function, making this proposal syntax sugar to N3413<= /b>.
//= this
template<Literal l&g= t; void func();
//differs only= through call syntax from this
void func(constexpr Literal l);

//yet this would allow to get rid of atrocious code like this
template<auto I= = >
constexpr auto func(std:integral_constant<decltype= = (I), I>); //only uses I= =
  • =C2=A0 =C2=A0The la= tter (is_constexpr) aims to allow a runtime or compile-time s= pecialization=C2=A0throu= gh a constexpr expression with a variant value. It would requires long if constexpr blocks=C2=A0as, if runtime specializat= ion is required, we can assume that the runtime and compile-time version wi= ll share very little code. It=C2=A0would also mean that, despite the confirmation by the com= piler that we are in constexpr context with arguments being compile-time ev= aluated, we would still be incapable=C2=A0to use those as such or would req= uire that if constexp(is_constexpr()) have side-effects (big = no-no).
constexpr auto func(int<= span style=3D"color:#000" class=3D"m_-5563334057486048styled-by-prettify"> = i)
{
=C2=A0 =C2=A0 =C2=A0 if constexpr (is_constexpr())<= span style=3D"color:#000" class=3D"m_-5563334057486048styled-by-prettify"><= br>=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 //i is still not usable as a constexpr
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 //long piece of code or call to other function = that handles the compile-time version
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 }=C2=A0 =C2=A0 =C2=A0 else
=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 //long piece of code or = call to other function that handles the runtime version
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0....
=C2=A0 =C2=A0 =C2= =A0 }
}
Now that the context has been presented here is my proposal wi= th a detailed and commented exemple.
My goal is to allow a big ch= unk of what the other proposal aimed to allow without all their issues and = in one proposal.
It is to allow constexpr-only specialization by = borrowing the noexcept syntax.
As the function may = only be constexpr it will not have linkage and therefor no mangling nor all= the issues associated with it.
Now here is a detailed exemple= .

<= span style=3D"color:#800" class=3D"m_-5563334057486048styled-by-prettify">/= /compile-time only function
//it will never have linkage
//all its arguments are constexpr
//a non-= constexpr expression usage in its definition will cause an error instead of= a fallback like normal constexpr
//is only called in an e= xplicit constexpr context unlike normal constexpr
constexp= r(true) auto func(<= span style=3D"color:#606" class=3D"m_-5563334057486048styled-by-prettify">L= iteral r);
//runtime specialization of func
/*constexpr(fals= e)*/ auto func(<= /span>Literal r); //constexpr(false) is the def= ault for functions and methods

//error redefinition of= 'constexpr(false) void func(Literal)'
constexpr void func();

constexpr(true) auto func2();
//allowed
//constexp= r is ignored, retains inline side effect
constexpr<= /span> auto func2();

constexpr auto func3();
constexpr auto error_0 =3D<= span style=3D"color:#000" class=3D"m_-5563334057486048styled-by-prettify"> = func3();
//constexpr specialization of 'func3&#= 39; after instanciation
constexpr(true) auto func3();

= = //addresses demands for partially constexpr argument-list
= = constexpr(true) void partial_co= nstexpr(int constant)
{= =
=C2=A0 =C2=A0return [&](auto&= ;&... runtime_args) constexpr /*this lambda has the default constexpr behavior*/ {<= span style=3D"color:#000" class=3D"m_-5563334057486048styled-by-prettify"><= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0//runtime code
=C2=A0 =C2=A0= =C2=A0 =C2=A0//can use 'constant' as a constexpr here
=C2=A0 =C2=A0};
}

int main()
{
=C2=A0 constexpr auto r_0 =3D func(Literal{}); //constexpr(true) version called
=C2=A0 auto r_1 =3D func(Literal{}); //constexpr(false) version called

=C2=A0 partial_constexpr(42<= span style=3D"color:#800" class=3D"m_-5563334057486048styled-by-prettify">/= *compile-time args*/)(/*runtime args*/);= =

=C2=A0 auto r_2 =3D constexpr func(Literal{}); //also proposed u= nary constexpr operator for explicit selection, error if the expression is = not constexpr
=C2=A0 //is equivalent to
=C2=A0 = auto r_3 =3D []() {= = constexpr auto __ret__ =3D func<= /span>(Literal{}); return __ret__= = ; }();
}

//replacing= of gnu's operator"" extension
constexpr(true) auto operator<= span style=3D"color:#080" class=3D"m_-5563334057486048styled-by-prettify">&= quot;"_string_literal(const ch= ar *str, size_t len)
{
=C2=A0 =C2=A0 return [&]<size_t... Indexs>(std::index_sequence<Indexs...>&&)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0re= turn TemplateCharSeq<str[Indexs]...<= wbr>>{};
=C2=A0 =C2=A0 }(std::ma= ke_index_sequence<len>{});
}

//operator[] for std::tuple
template <class... Args>= =
struct tuple
{
=C2=A0 =C2=A0= = ....
=C2=A0 =C2=A0constexpr(true) auto& operator[](size_t = i) const
=C2=A0 =C2=A0{
=C2= =A0 =C2=A0 =C2=A0 static_assert(i <= = sizeof...(Args));
=C2=A0 =C2=A0 =C2= =A0 return std::get<i>(*this);
=C2=A0 =C2=A0}

=C2=A0 =C2= =A0constexpr(true) auto& operator[](size_t = i)
=C2=A0 =C2=A0{
=C2=A0 = =C2=A0 =C2=A0 static_assert(i < sizeof...(Args));
=C2=A0 =C2=A0 =C2=A0 <= /span>return std::get<i>(*<= span style=3D"color:#008" class=3D"m_-5563334057486048styled-by-prettify">t= his); =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0}=C2=A0 =C2=A0....
};

template= <class... Args> struct Select : Args... { using Args::operator()...; };<= span style=3D"color:#000" class=3D"m_-5563334057486048styled-by-prettify"><= br>template <class...<= span style=3D"color:#000" class=3D"m_-5563334057486048styled-by-prettify"> = Args> Select(Args&&= amp;...) -> Select<Args...>;

//for lambdas
void= = func_3()
{
=C2=A0 constexpr auto f_0 =3D []() {}; //operator() is constexp= r /*fallback on runtime*/, no changes
=C2=A0 constexpr auto f_1 =3D []() co= nstexpr(false) {}; //oper= ator() cannot be called at compile-time
=C2=A0 constexpr auto f_2 =3D []() constexpr(true) {}= ; //operator() can only be called a compile-time and explicit= ly

=C2=A0 constexpr Select f_3 =3D { f_= 1, f_2 };

=C2=A0 constexpr auto r_4 =3D f_3(); //f_2
=C2=A0 auto r_5 <= /span>=3D f_3(); //f_1
}

Here is the summary:

- extend constexpr specifier to allow it to take a conste= xpr explicit bool (no a constexpr expression unless if there are good use-c= ases for it) where:
  • constexpr(false) is the default speci= fier of a function/method
    • optional for functions/method.
      • if specified with lambdas allows not-constexpr lambda as lambdas are by d= efault constexpr.
  • constexpr(true) is a constexpr only function= ..
    • no Assembly representation (no linkage nor mangling).
      • all arguments are constexpr.
    • error if non-constexpr expression is = used (a constexpr fallback to runtime because of an overflow for instance).=
    • only used in explicit constexpr context.
    • cannot be called = before its specialization if specialization or else error.
    constexpr
    • keeps all its properties and definition.
    • wil= l still trigger redefinition error if previous constexpr(false) version pre= viously defined.
    • constexpr attribute ignored if previous constexpr(= true) is defined.
- unary constexpr operator to re= quest a constexpr expression explicitly:
=C2=A0 =C2=A0auto t =3D= = constexpr expr; //might error if expr i= s no a constexpr expression

The reason why I b= elieve in this proposal:
  • no new keyword.
  • zero run= time impact.
  • maintains backward compatibility.
  • solves, at l= east partially, a lot of different proposals.
Thanks in advan= ce,

Bastien Penavayre,

--
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-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/17e1= 56a0-0368-4ec0-a087-e8b4bc8d9f62%40isocpp.org.

--
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/CA%2BfGSbMtne= hJhDx3Bz_GfxsqyrK_ch5hes7aGZqnufrimtG%3DgQ%40mail.gmail.com.
--94eb2c1fb964f4ccea05581255cf-- .