220 38620 <8b0f4065-6614-4d0f-b62f-ea2ac3003e13@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: cshay892@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Proposing addition to proposal std::is_constant_evaluated (P0595R1) to accept a variable argument Date: Wed, 13 Jun 2018 18:18:38 -0700 (PDT) Lines: 434 Approved: news@gmane.org Message-ID: <8b0f4065-6614-4d0f-b62f-ea2ac3003e13@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_968_806851385.1528939118891" X-Trace: blaine.gmane.org 1528938995 11190 195.159.176.226 (14 Jun 2018 01:16:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 14 Jun 2018 01:16:35 +0000 (UTC) Cc: richard@metafoo.co.uk, andrew.n.sutton@gmail.com, daveed@edg.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDR3RUOIVUHBB4EEQ7MQKGQE32SPV5Y@isocpp.org Thu Jun 14 03:16:30 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f199.google.com ([209.85.213.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fTGsI-0002mk-2l for gclcip-std-proposals@m.gmane.org; Thu, 14 Jun 2018 03:16:30 +0200 Original-Received: by mail-yb0-f199.google.com with SMTP id h10-v6sf3423486ybq.14 for ; Wed, 13 Jun 2018 18:18:41 -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:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=dm+YOiUfbDIG0Z5grIMbvNcu5guPWZWQtdSLTX2vJcI=; b=LN3eIa3VjbnBFN7yqwCwH09nhJsZ0vQeIwMJ6Xq73uVid1oW9+wFRQHnSA4A86d/Rw yStbFmEbcwE5y1xcuTzizXMSScbGmEahypcqis6y+t+jbiEIqnOG24ZWxehaQ+DTjFQP I9EfNh3kYNQQEQ5pobm7RGo+Jro+NdukrKKxugWDX7E4j4VBEpTNDfd1wKfV3aP6m3Yb f24t2ArhPvwFG0UIKydktceECA7UOqrenz3u89IMvaUa8SBR3tTmS9iRLfK3l3Ca1M83 INKa4vg1qyqd2WTPIHoyudGB2J7zcPiADMDECwlFF+V0lnah7ztA7V13EJacnlGouRuq iLCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=dm+YOiUfbDIG0Z5grIMbvNcu5guPWZWQtdSLTX2vJcI=; b=TTaMReB1ga/ungHEvSQGAR27+28M5HVTZSYbaY2At1aWkdHoCLEcYdx1MhlhEdiyey lBbpVsmVsPXH0TPkkTnyEkGinjl4Zj5ZSqWAIrkFF1gKaxwVjF445I4m7se8A0g82PcY Q1sKC8EK/OPi5a9opa4zs3TkaTJMDIjx6OrM2Tco5TPVzhErH3kEPNTGaF86XMv3kp1H U5BMg4D+ykNZZA/kfBcq/SHVQcaaajYXBwQXDvtLATyo3O4VZm/ERUS03wi8vHmmGpTj 55iSX5v6bZC75UBjL+pocAC7QArcYanROifFEvoLTwu78WajnTOankp/DKhrX8pRYauE ddEA== 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: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=dm+YOiUfbDIG0Z5grIMbvNcu5guPWZWQtdSLTX2vJcI=; b=DCiTtfs5DgyLsPAKMPPSBdP4fiQjtdAsD73WgBEWKFjhBfHMcWjVRqHqvkPxncA/f/ JxbskSZRiiFtsCde4GVU4DFzg7Db+9HrsDR6BbLhrTjN4QbgpdQI9BBn8hmdquM1/pBo Yk57DMXtpxTbNGFM/E/yWzpNDkUUQaNdfftw3JvTwu1JmOaIjCkiSjnvpI1d8dkyiynP OLkbkCW2pp3mPefhGoYaYRJWrnfDtMBV6LwtzZ+NyeCeGN+e8AGp8KZWgrXz7oVRMkqU CqKmxxlXEe3rILZ5fNKjNTNaORhiJ2q158WAOO4DKiUkUszun3OM2g0SMKsYLulNSJGo szHQ== X-Gm-Message-State: APt69E3rIgUdvXKSE1yUELgGh8AmcHsNh1TWY3A0pHWXJ0KooviXBPUo l6fgRN2s+vyy6hBqyoEoZ3V/WQ== X-Google-Smtp-Source: ADUXVKIRzK5YoKrxyAYmh+oq0ByDBjGlgLMJPHP1V47ji7xE/ZZCHiAVoavyMqu1ncTiMuvjRYD9Qw== X-Received: by 2002:a81:56c2:: with SMTP id k185-v6mr149048ywb.144.1528939121075; Wed, 13 Jun 2018 18:18:41 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:44c:: with SMTP id 73-v6ls1846709ybe.11.gmail; Wed, 13 Jun 2018 18:18:39 -0700 (PDT) X-Received: by 2002:a25:cf13:: with SMTP id f19-v6mr401147ybg.5.1528939119607; Wed, 13 Jun 2018 18:18:39 -0700 (PDT) X-Original-Sender: cshay892@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:38620 Archived-At: ------=_Part_968_806851385.1528939118891 Content-Type: multipart/alternative; boundary="----=_Part_969_1868755123.1528939118893" ------=_Part_969_1868755123.1528939118893 Content-Type: text/plain; charset="UTF-8" The proposal P0595R1, as it is currently stated, in my opinion, would be a wonderful addition to C++. However I believe that there could be another potential use case for std::is_constant_evaluated, in which it accepts a variable as an argument. The expression would return true if and only if the compiler is already aware of the value of the variable itself. The motivation behind this is to address proposals for constexpr variable function arguments and similar situations, but could sidestep the potential pitfalls of function overloading. But it allows the programmer to leverage inline optimizations that the compiler is often already doing by making him/her aware of when those optimizations are applied. Declared something like this: namespace std { // Already in P0595R1. This returns true if the compiler is evaluating the function itself in constexpr context. constexpr bool is_constant_evaluated() noexcept; // Returns true if the literal value of variable t is known to the compiler. template constexpr bool is_constant_evaluated(T t) noexcept; } Example usage: inline constexpr float MyPow(float x, float y) { if constexpr (std::is_constant_evaluated()) { return 0; // TODO: Make a compile-time friendly pow function } else if constexpr (std::is_constant_evaluated(y)) { if constexpr (y == 0.f) return 1.f; if constexpr (y == 1.f) return x; if constexpr (y == 2.f) return x * x; if constexpr (y == 3.f) return x * x * x; else return powf(x, y); } else return powf(x, y); } float g_x, g_y; // globally mutable, always evaluated at runtime int main() { constexpr float a = MyPow(3.14f, 2.5f); // MyPow takes the first if block and returns a value computed at compile-time float b = MyPow(g_x, 2.0f); // Compiler inlines: float b = g_x * g_x; float c = MyPow(g_x, 1.0f); // Compiler inlines: float c = g_x; float d = MyPow(g_x, g_y); // Compiler inlines: float d = powf(g_x, g_y); float y = 0.f; float e = MyPow(g_x, y); // Optimizing compiler SHOULD inline: float e = 1.0f; Because y is known at compile time. return 0; } This of course makes the assumption that the compiler is obligated to skip compilation of code that fails the constexpr if conditional where it would instead compile the code in the else blocks, and vice versa where the if constexpr passes. It's also worth mentioning that there should be no guarantee that just because a variable is assigned to a literal and then immediately queried for std::is_constant_evaluated that it will return true. It's up to the compiler to respect this case only when the variable is optimized in a way to be treated as such. For example, it may return false in a non-optimized build, but true in an optimized build where inline expansion is guaranteed. As far as the preceding example goes, yes, I went straight to the float use case, which is normally non-integral, but I wanted to also demonstrate that this works around the issue where floats cannot be template arguments in a more elegant and uniformly obvious way where a function author can optimize for specific cases and combinations of literal values. -- 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/8b0f4065-6614-4d0f-b62f-ea2ac3003e13%40isocpp.org. ------=_Part_969_1868755123.1528939118893 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The proposal P0595R1, as it is currently stated, in my opi= nion, would be a wonderful addition to C++. However I believe that there co= uld be another potential use case for std::is_constant_evaluated, in which = it accepts a variable as an argument. The expression would return true if a= nd only if the compiler is already aware of the value of the variable itsel= f. The motivation behind this is to address proposals for constexpr variabl= e function arguments and similar situations, but could sidestep the potenti= al pitfalls of function overloading. But it allows the programmer to levera= ge inline optimizations that the compiler is often already doing by making = him/her aware of when those optimizations are applied.

<= div>Declared something like this:
namespace std
{
=C2=A0 =C2=A0 // Already in P0595R1. This returns true if the= compiler is evaluating the function itself in constexpr context.
=C2=A0 =C2=A0 constexpr bool is_constant_evaluated() noexcept;


=C2=A0 =C2=A0 <= span style=3D"color: #800;" class=3D"styled-by-prettify">// Returns true if= the literal value of variable t is known to the compiler.
=C2=A0 =C2=A0 template <typename T>
=C2=A0 =C2=A0 constexpr bool is_constant_evaluated(T t) noexcept;
<= /span>}


Example usage:
inline = constexpr<= /span> float MyPow(float x, fl= oat y)
{
=C2=A0 =C2=A0 if constexpr (std::is_c= onstant_evaluated())=
=C2=A0 =C2=A0 {<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;= // TODO: Make a com= pile-time friendly pow function
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 else if co= nstexpr (std::is_constant_evaluated(y))
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if constexpr (y =3D=3D = 0.f= )
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 return 1.= f;<= span style=3D"color: #000;" class=3D"styled-by-prettify">
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 if constexpr (y =3D=3D 1.f)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return x;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if constexpr (y =3D=3D = 2.f= )
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 return x = * x= ;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 if<= /span> constexpr (y =3D=3D 3.f)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return x * x * x;
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return powf(x, y);
=C2=A0 =C2= =A0 }
=C2=A0 =C2= =A0 else
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 return powf(x, y);
}


float g_x, g_y; // globally mutable, al= ways evaluated at runtime
int main()<= /span>
= {
=C2=A0 =C2=A0 <= span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr float a =3D MyPow(3.14f= , <= span style=3D"color: #066;" class=3D"styled-by-prettify">2.5f); // MyPow takes the first if block and ret= urns a value computed at compile-time
=C2=A0 =C2=A0 float b =3D MyPow(g_x, 2.0f); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Compiler = inlines: float b =3D g_x * g_x;
=C2=A0 =C2=A0 float c =3D MyPow(g_x, 1.0f); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= span style=3D"color: #800;" class=3D"styled-by-prettify">// Compiler inline= s: float c =3D g_x;
=C2=A0 =C2=A0 float d =3D <= /span>MyPow(g_x, g_y); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Compiler inli= nes: float d =3D powf(g_x, g_y);


=C2=A0 =C2=A0 float y =3D 0.f;
= =C2=A0 =C2=A0 float = e =3D MyPow(g_x, y); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Optimizing<= span style=3D"color: #800;" class=3D"styled-by-prettify"> compiler SHOULD i= nline: float e =3D 1.0f; Because y is known at compile time.


=C2=A0 =C2=A0= return 0;
}


This of course makes the assumption that the compiler is ob= ligated to skip compilation of code that fails the constexpr if conditional= where it would instead compile the code in the else blocks, and vice versa= where the if constexpr passes. It's also worth mentioning that there s= hould be no guarantee that just because a variable is assigned to a literal= and then immediately queried for std::is_constant_evaluated that it will r= eturn true. It's up to the compiler to respect this case only when the = variable is optimized in a way to be treated as such. For example, it may r= eturn false in a non-optimized build, but true in an optimized build where = inline expansion is guaranteed.

As far as the prec= eding example goes, yes, I went straight to the float use case, which is no= rmally non-integral, but I wanted to also demonstrate that this works aroun= d the issue where floats cannot be template arguments in a more elegant and= uniformly obvious way where a function author can optimize for specific ca= ses and combinations of literal values.

--
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/8b0f4065-6614-4d0f-b62f-ea2ac3003e13= %40isocpp.org.
------=_Part_969_1868755123.1528939118893-- ------=_Part_968_806851385.1528939118891-- .