------=_Part_170_748270934.1411836139400
Content-Type: text/plain; charset=UTF-8

Problem:
Using assertions in a `constexpr` function is currently not possible in
C++14.
As `constexpr` is used more and more, it has become a necessity (at least
for me) to have a tool that allows me to perform debug checks on
`constexpr` functions.

Currently, there are no elegant or obvious ways to replicate the behavior
of assertions in `constexpr` functions.
http://stackoverflow.com/questions/26072709/alternative-to-asserts-for-constexpr-functions
http://stackoverflow.com/questions/18648069/g-doesnt-compile-constexpr-function-with-assert-in-it/



Proposal:
I propose a new standard function/macro/whatever that allows the developer
to assert certain predicates in `constexpr` functions.

constexpr int getClamped(int mValue, int mMin, int mMax) noexcept
{
    // constexpr_assert(<predicate>, <optional message>);
    constexpr_assert(mMin < mMax, "mMin must be smaller than mMax");

    return mValue < mMin ? mMin : ((mValue > mMax) ? mMax : mValue);
}

int main()
{
    // "Obvious" compile-time evaluation
    std::array<int, getClamped(5, 3, 4)> array;

    // "Obvious" run-time evaluation
    int x; std::cin >> x;
    std::cout << getClamped(5, x, 10);

    return 0;
}

`constexpr_assert(...)` would work very similarly to `assert(...)`. The
user can specify an optional message as well.

Now, there are two cases:

   - *"Obvious" compile-time evaluation: *we are sure the `constexpr`
   function is being evaluated at compile-time.
      - *Ideal solution:* the compiler can verify the assertion predicate
      at compile time and emit a compiler error in case the predicate is false.
      - *Good-enough solution: *the compiler completely skips the assertion
      check, allowing the code to compile properly and run. The assertion will
      still work in "obvious" run-time evaluation scenarios.
   - *"Obvious" run-time evaluation: *we are sure the `constexpr` function
   is being evaluated at run-time.
      - The assertion is practically treated as a normal `assert(...)`,
      with the addition of an optional message that will displayed in case it
      fires.



Finishing thoughts:
If this gets implemented, I think the standard should not require (but
definitely encourage) compilers to be able to evaluate and check
`constexpr_assert` assertions in "obvious" compile-time scenarios.
The most important requirement would be allowing `constexpr` functions with
`constexpr_assert` in them to always compile, independently on the fact
that they're being evaluated at compile-time or run-time.
In run-time scenarios, it's very simple to basically treat the
`constexpr_assert` call as a normal assertion.

What do you think?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_170_748270934.1411836139400
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><font size=3D"4">Problem:</font></div>Using assertion=
s in a `constexpr` function is currently not possible in C++14.&nbsp;<div>A=
s `constexpr` is used more and more, it has become a necessity (at least fo=
r me) to have a tool that allows me to perform debug checks on `constexpr` =
functions.</div><div><br></div><div>Currently, there are no elegant or obvi=
ous ways to replicate the behavior of assertions in `constexpr` functions.<=
/div><div><a href=3D"http://stackoverflow.com/questions/26072709/alternativ=
e-to-asserts-for-constexpr-functions">http://stackoverflow.com/questions/26=
072709/alternative-to-asserts-for-constexpr-functions</a><br></div><div><a =
href=3D"http://stackoverflow.com/questions/18648069/g-doesnt-compile-conste=
xpr-function-with-assert-in-it/">http://stackoverflow.com/questions/1864806=
9/g-doesnt-compile-constexpr-function-with-assert-in-it/</a><br></div><div>=
<br></div><div><br></div><div><br></div><div><font size=3D"4">Proposal:</fo=
nt></div><div><font size=3D"2">I propose a new standard function/macro/what=
ever that allows the developer to assert certain predicates in `constexpr` =
functions.</font></div><div><font size=3D"2"><br></font></div><div><font si=
ze=3D"2"><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187=
, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code=
 class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: =
#008;" class=3D"styled-by-prettify">constexpr</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> getClamped</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> mValue</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> mMin</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> mMax</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> noexcept<br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>&nbsp; &nbsp; </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// constexpr_assert(&lt;predicate&gt;, &lt;optional message&gt;=
);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; &nbsp; constexpr_assert</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">mMin </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> mMa=
x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #080;" class=3D"styled-by-prettify">"mMin must be smaller than =
mMax"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>&nbsp=
; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">r=
eturn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> mVal=
ue </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> mMin </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">?</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><font color=3D"#66=
6600"><span style=3D"color: #000;" class=3D"styled-by-prettify">mMin </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">((</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">mValue </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> mMax</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>?</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> mMax </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> mValue</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">);</span></font><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> main</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>&nbsp; &nbsp; </span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">// "Obvious" compile-time evaluation</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; std</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">array</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> getClamped</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">=
5</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #066;" class=3D"styled-by-prettify">3</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D=
"styled-by-prettify">4</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">)&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> array</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><b=
r>&nbsp; &nbsp; </span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">// "Obvious" run-time evaluation</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><font color=3D"#000000"><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">cin </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&gt;&gt;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
<br>&nbsp; &nbsp; std</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">cout </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> get=
Clamped</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">5</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D=
"styled-by-prettify">10</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pretti=
fy">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span></font></div=
></code></div><br>`constexpr_assert(...)` would work very similarly to `ass=
ert(...)`. The user can specify an optional message as well.</font></div><d=
iv><font size=3D"2"><br></font></div><div><font size=3D"2">Now, there are t=
wo cases:</font></div><div><ul><li><font size=3D"2"><span style=3D"line-hei=
ght: normal;"><b>"Obvious" compile-time evaluation: </b>we are sure the `co=
nstexpr` function is being evaluated at compile-time.</span></font></li><ul=
><li><font size=3D"2"><span style=3D"line-height: normal;"><b>Ideal solutio=
n:</b> the compiler can verify the assertion predicate at compile time and =
emit a compiler error in case the predicate is false.</span></font></li><li=
><font size=3D"2"><span style=3D"line-height: normal;"><b>Good-enough solut=
ion: </b>the compiler completely skips the assertion check, allowing the co=
de to compile properly and run. The assertion will still work in "obvious" =
run-time evaluation scenarios.</span></font></li></ul><li><font size=3D"2">=
<span style=3D"line-height: normal;"><b>"Obvious" run-time evaluation: </b>=
we are sure the `constexpr` function is being evaluated at run-time.</span>=
</font></li><ul><li><font size=3D"2"><span style=3D"line-height: normal;">T=
he assertion is practically treated as a normal `assert(...)`, with the add=
ition of an optional message that will displayed in case it fires.</span></=
font></li></ul></ul><div><br></div></div><div><br></div><div><font size=3D"=
4">Finishing thoughts:</font></div><div><font size=3D"2">If this gets imple=
mented, I think the standard should not require (but definitely encourage) =
compilers to be able to evaluate and check `constexpr_assert` assertions in=
 "obvious" compile-time scenarios.&nbsp;</font></div><div><font size=3D"2">=
The most important requirement would be allowing `constexpr` functions with=
 `constexpr_assert` in them to always compile, independently on the fact th=
at they're being evaluated at compile-time or run-time.</font></div><div>In=
 run-time scenarios, it's very simple to basically treat the `constexpr_ass=
ert` call as a normal assertion.<br><br>What do you think?</div><div><font =
size=3D"4"><br></font></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_170_748270934.1411836139400--

.

--part5014-boundary-1402840604-1515643058
Content-Type: text/plain; charset=UTF-8

I would just prefere to allow static_assert in constexpr functions and DTRT rather than invent a new thing foe the same purpose.
-----Original Message-----
From: Vittorio Romeo <vittorio.romeo.vee@gmail.com>
Date: Sat, 27 Sep 2014 09:42:19
To: <std-proposals@isocpp.org>
Reply-To: std-proposals@isocpp.org
Subject: [std-proposals] `constexpr_assert(...)`

Problem:
Using assertions in a `constexpr` function is currently not possible in
C++14.
As `constexpr` is used more and more, it has become a necessity (at least
for me) to have a tool that allows me to perform debug checks on
`constexpr` functions.

Currently, there are no elegant or obvious ways to replicate the behavior
of assertions in `constexpr` functions.
http://stackoverflow.com/questions/26072709/alternative-to-asserts-for-constexpr-functions
http://stackoverflow.com/questions/18648069/g-doesnt-compile-constexpr-function-with-assert-in-it/



Proposal:
I propose a new standard function/macro/whatever that allows the developer
to assert certain predicates in `constexpr` functions.

constexpr int getClamped(int mValue, int mMin, int mMax) noexcept
{
    // constexpr_assert(<predicate>, <optional message>);
    constexpr_assert(mMin < mMax, "mMin must be smaller than mMax");

    return mValue < mMin ? mMin : ((mValue > mMax) ? mMax : mValue);
}

int main()
{
    // "Obvious" compile-time evaluation
    std::array<int, getClamped(5, 3, 4)> array;

    // "Obvious" run-time evaluation
    int x; std::cin >> x;
    std::cout << getClamped(5, x, 10);

    return 0;
}

`constexpr_assert(...)` would work very similarly to `assert(...)`. The
user can specify an optional message as well.

Now, there are two cases:

   - *"Obvious" compile-time evaluation: *we are sure the `constexpr`
   function is being evaluated at compile-time.
      - *Ideal solution:* the compiler can verify the assertion predicate
      at compile time and emit a compiler error in case the predicate is false.
      - *Good-enough solution: *the compiler completely skips the assertion
      check, allowing the code to compile properly and run. The assertion will
      still work in "obvious" run-time evaluation scenarios.
   - *"Obvious" run-time evaluation: *we are sure the `constexpr` function
   is being evaluated at run-time.
      - The assertion is practically treated as a normal `assert(...)`,
      with the addition of an optional message that will displayed in case it
      fires.



Finishing thoughts:
If this gets implemented, I think the standard should not require (but
definitely encourage) compilers to be able to evaluate and check
`constexpr_assert` assertions in "obvious" compile-time scenarios.
The most important requirement would be allowing `constexpr` functions with
`constexpr_assert` in them to always compile, independently on the fact
that they're being evaluated at compile-time or run-time.
In run-time scenarios, it's very simple to basically treat the
`constexpr_assert` call as a normal assertion.

What do you think?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--part5014-boundary-1402840604-1515643058
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head><=
meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type"></h=
ead><body>I would just prefere to allow static_assert in constexpr function=
s and DTRT rather than invent a new thing foe the same purpose.<hr/><div><b=
>From: </b> Vittorio Romeo &lt;vittorio.romeo.vee@gmail.com&gt;
</div><div><b>Date: </b>Sat, 27 Sep 2014 09:42:19 -0700 (PDT)</div><div><b>=
To: </b>&lt;std-proposals@isocpp.org&gt;</div><div><b>ReplyTo: </b> std-pro=
posals@isocpp.org
</div><div><b>Subject: </b>[std-proposals] `constexpr_assert(...)`</div><di=
v><br/></div><div dir=3D"ltr"><div><font size=3D"4">Problem:</font></div>Us=
ing assertions in a `constexpr` function is currently not possible in C++14=
..&nbsp;<div>As `constexpr` is used more and more, it has become a necessity=
 (at least for me) to have a tool that allows me to perform debug checks on=
 `constexpr` functions.</div><div><br></div><div>Currently, there are no el=
egant or obvious ways to replicate the behavior of assertions in `constexpr=
` functions.</div><div><a href=3D"http://stackoverflow.com/questions/260727=
09/alternative-to-asserts-for-constexpr-functions">http://stackoverflow.com=
/questions/26072709/alternative-to-asserts-for-constexpr-functions</a><br><=
/div><div><a href=3D"http://stackoverflow.com/questions/18648069/g-doesnt-c=
ompile-constexpr-function-with-assert-in-it/">http://stackoverflow.com/ques=
tions/18648069/g-doesnt-compile-constexpr-function-with-assert-in-it/</a><b=
r></div><div><br></div><div><br></div><div><br></div><div><font size=3D"4">=
Proposal:</font></div><div><font size=3D"2">I propose a new standard functi=
on/macro/whatever that allows the developer to assert certain predicates in=
 `constexpr` functions.</font></div><div><font size=3D"2"><br></font></div>=
<div><font size=3D"2"><div class=3D"prettyprint" style=3D"border: 1px solid=
 rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250,=
 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> getClamped</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> mValue</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> mMin</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> mMax</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> noexcept<br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// constexpr_assert(&lt;predicate&gt;, &lt;optional=
 message&gt;);</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>&nbsp; &nbsp; constexpr_assert</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">mMin </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> mMax</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #080;" class=3D"styled-by-prettify">"mMin must be s=
maller than mMax"</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> mValue </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
mMin </span><span style=3D"color: #660;" class=3D"styled-by-prettify">?</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><font =
color=3D"#666600"><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>mMin </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">((</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">mValue </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> mMax</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">?</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> mMax </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> mValue=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
/font><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> main</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">// "Obvious" compile-time evaluation</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">array</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> getClamped</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"sty=
led-by-prettify">5</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">3</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">4</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> array</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br><br>&nbsp; &nbsp; </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// "Obvious" run-time evaluation</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><font color=3D"#000000"><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">cin </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&gt;&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> <br>&nbsp; &nbsp; std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">cout </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> getClamped</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">5</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">10</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br>&nbsp; &nbsp; </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
}</span></font></div></code></div><br>`constexpr_assert(...)` would work ve=
ry similarly to `assert(...)`. The user can specify an optional message as =
well.</font></div><div><font size=3D"2"><br></font></div><div><font size=3D=
"2">Now, there are two cases:</font></div><div><ul><li><font size=3D"2"><sp=
an style=3D"line-height: normal;"><b>"Obvious" compile-time evaluation: </b=
>we are sure the `constexpr` function is being evaluated at compile-time.</=
span></font></li><ul><li><font size=3D"2"><span style=3D"line-height: norma=
l;"><b>Ideal solution:</b> the compiler can verify the assertion predicate =
at compile time and emit a compiler error in case the predicate is false.</=
span></font></li><li><font size=3D"2"><span style=3D"line-height: normal;">=
<b>Good-enough solution: </b>the compiler completely skips the assertion ch=
eck, allowing the code to compile properly and run. The assertion will stil=
l work in "obvious" run-time evaluation scenarios.</span></font></li></ul><=
li><font size=3D"2"><span style=3D"line-height: normal;"><b>"Obvious" run-t=
ime evaluation: </b>we are sure the `constexpr` function is being evaluated=
 at run-time.</span></font></li><ul><li><font size=3D"2"><span style=3D"lin=
e-height: normal;">The assertion is practically treated as a normal `assert=
(...)`, with the addition of an optional message that will displayed in cas=
e it fires.</span></font></li></ul></ul><div><br></div></div><div><br></div=
><div><font size=3D"4">Finishing thoughts:</font></div><div><font size=3D"2=
">If this gets implemented, I think the standard should not require (but de=
finitely encourage) compilers to be able to evaluate and check `constexpr_a=
ssert` assertions in "obvious" compile-time scenarios.&nbsp;</font></div><d=
iv><font size=3D"2">The most important requirement would be allowing `const=
expr` functions with `constexpr_assert` in them to always compile, independ=
ently on the fact that they're being evaluated at compile-time or run-time.=
</font></div><div>In run-time scenarios, it's very simple to basically trea=
t the `constexpr_assert` call as a normal assertion.<br><br>What do you thi=
nk?</div><div><font size=3D"4"><br></font></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

</body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--part5014-boundary-1402840604-1515643058--


.

------=_Part_1616_2094590296.1411846432496
Content-Type: text/plain; charset=UTF-8



On Saturday, 27 September 2014 17:42:19 UTC+1, Vittorio Romeo wrote:
>
> If this gets implemented, I think the standard should not require (but
> definitely encourage) compilers to be able to evaluate and check
> `constexpr_assert` assertions in "obvious" compile-time scenarios.
>

My feeling is that if constexpr_assert were to be standardised, it should
be mandated that the assertion be checked for constexpr functions (even the
suggested name would imply this ;) ).

I agree with dgutson  that the better solution would be to allow
static_assert to be extended to constexpr functions, though.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1616_2094590296.1411846432496
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, 27 September 2014 17:42:19 UTC+1, Vit=
torio Romeo  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><font size=3D"2">If this gets implemented, I think the standard shoul=
d not require (but definitely encourage) compilers to be able to evaluate a=
nd check `constexpr_assert` assertions in "obvious" compile-time scenarios.=
&nbsp;</font></div></blockquote><div><br>My feeling is that if constexpr_as=
sert were to be standardised, it should be mandated that the assertion be c=
hecked for constexpr functions (even the suggested name would imply this ;)=
 ).<br><br>I agree with dgutson&nbsp; that the better solution would be to =
allow static_assert to be extended to constexpr functions, though.<br></div=
></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1616_2094590296.1411846432496--

.

--_7384de5f-7251-4ce4-97c1-09f08f774d10_
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'm kind-of against extending `static_assert(...)` to work with `constexpr`=
 function because it's not really the same as compile-time evaluation - tak=
e the code in my proposal, for example: there are normal `int` parameters `=
mValue`, `mMax` and `mMin`.=20

Those can be used both at run-time and compile-time.=20

Does it make sense to say `static_assert(mMin < mMax)`? `mMin` and `mMax` a=
re just "normal" integers. They can sometimes behave as compile-time values=
 because of the `constexpr` keyword - that's why I don't think `static_asse=
rt(...)` is the right choice here.

Also, when they are used/evaluated at run-time (for example, after reading =
them from `std::cin`), `static_assert(...)` makes even less sense to me - t=
here's nothing `static` here.

Date: Sat, 27 Sep 2014 12:33:52 -0700
From: douglas.boffey@gmail.com
To: std-proposals@isocpp.org
Subject: [std-proposals] Re: `constexpr_assert(...)`



On Saturday, 27 September 2014 17:42:19 UTC+1, Vittorio Romeo  wrote:If thi=
s gets implemented, I think the standard should not require (but definitely=
 encourage) compilers to be able to evaluate and check `constexpr_assert` a=
ssertions in "obvious" compile-time scenarios.=20
My feeling is that if constexpr_assert were to be standardised, it should b=
e mandated that the assertion be checked for constexpr functions (even the =
suggested name would imply this ;) ).

I agree with dgutson  that the better solution would be to allow static_ass=
ert to be extended to constexpr functions, though.





--=20



---=20

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 e=
mail to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-proposals@isocpp.org.

Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
           =20

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--_7384de5f-7251-4ce4-97c1-09f08f774d10_
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
..hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'>I'm kind-of against extending `s=
tatic_assert(...)` to work with `constexpr` function because it's not reall=
y the same as compile-time evaluation - take the code in my proposal, for e=
xample: there are normal `int` parameters `mValue`, `mMax` and `mMin`.&nbsp=
;<br><br>Those can be used both at run-time and compile-time.&nbsp;<br><br>=
Does it make sense to say `static_assert(mMin &lt; mMax)`? `mMin` and `mMax=
` are just "normal" integers.&nbsp;<div>They can sometimes behave as compil=
e-time values because of the `constexpr` keyword - that's why I don't think=
 `static_assert(...)` is the right choice here.<br><br>Also, when they are =
used/evaluated at run-time (for example, after reading them from `std::cin`=
), `static_assert(...)` makes even less sense to me - there's nothing `stat=
ic` here.<br><br><div><hr id=3D"stopSpelling">Date: Sat, 27 Sep 2014 12:33:=
52 -0700<br>From: douglas.boffey@gmail.com<br>To: std-proposals@isocpp.org<=
br>Subject: [std-proposals] Re: `constexpr_assert(...)`<br><br><div dir=3D"=
ltr"><br><br>On Saturday, 27 September 2014 17:42:19 UTC+1, Vittorio Romeo =
 wrote:<blockquote class=3D"ecxgmail_quote" style=3D"border-left:1px #ccc s=
olid;padding-left:1ex;"><div dir=3D"ltr"><font size=3D"2">If this gets impl=
emented, I think the standard should not require (but definitely encourage)=
 compilers to be able to evaluate and check `constexpr_assert` assertions i=
n "obvious" compile-time scenarios.&nbsp;</font></div></blockquote><div><br=
>My feeling is that if constexpr_assert were to be standardised, it should =
be mandated that the assertion be checked for constexpr functions (even the=
 suggested name would imply this ;) ).<br><br>I agree with dgutson&nbsp; th=
at the better solution would be to allow static_assert to be extended to co=
nstexpr functions, though.<br></div></div>

<BR>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br></div></div>            </div></body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--_7384de5f-7251-4ce4-97c1-09f08f774d10_--

.

On 27/09/2014 04:33 p.m., Douglas Boffey wrote:
>
>
> On Saturday, 27 September 2014 17:42:19 UTC+1, Vittorio Romeo wrote:
>
>     If this gets implemented, I think the standard should not require
>     (but definitely encourage) compilers to be able to evaluate and
>     check `constexpr_assert` assertions in "obvious" compile-time
>     scenarios.
>
>
> My feeling is that if constexpr_assert were to be standardised, it
> should be mandated that the assertion be checked for constexpr functions
> (even the suggested name would imply this ;) ).
>
> I agree with dgutson  that the better solution would be to allow
> static_assert to be extended to constexpr functions, though.
>

static_assert is and always was allowed in a constexpr function. The=20
intent of the OP, at least as I understand it, is to be able to use=20
assert in a constexpr function. It's hard to see that happening, given=20
that assert is a replaceable macro and all, so constexpr_assert seems=20
fair enough. Note in particular that as any other constant expression,=20
it would be perfectly fine to use it in a context that is not a constant=20
expression.

Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 27 September 2014 22:51, Agust=C3=ADn K-ballo Berg=C3=A9 <kaballo86@hotm=
ail.com> wrote:
> static_assert is and always was allowed in a constexpr function. The inte=
nt

Not to be pedantic (ha ha), but allowing static_assert in a constexpr funct=
ion
got into c++11 on the 11th hour just before the final standard draft
was accepted
for balloting.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_395_1056512606.1411851577001
Content-Type: text/plain; charset=UTF-8

On Saturday, September 27, 2014 5:52:55 PM UTC-3, Ville Voutilainen wrote:
>
> Not to be pedantic (ha ha), but allowing static_assert in a constexpr
> function
> got into c++11 on the 11th hour just before the final standard draft
> was accepted
> for balloting.
>

But was it supposed to allow a non-constexpr condition, like in Vittorio's
example?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_395_1056512606.1411851577001
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, September 27, 2014 5:52:55 PM UTC-3, Ville Vo=
utilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Not to be peda=
ntic (ha ha), but allowing static_assert in a constexpr function
<br>got into c++11 on the 11th hour just before the final standard draft
<br>was accepted
<br>for balloting.
<br></blockquote><div><br>But was it supposed to allow a non-constexpr cond=
ition, like in Vittorio's example?<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_395_1056512606.1411851577001--

.

On 27 September 2014 23:59, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On Saturday, September 27, 2014 5:52:55 PM UTC-3, Ville Voutilainen wrote:
>>
>> Not to be pedantic (ha ha), but allowing static_assert in a constexpr
>> function
>> got into c++11 on the 11th hour just before the final standard draft
>> was accepted
>> for balloting.
>
>
> But was it supposed to allow a non-constexpr condition, like in Vittorio's
> example?


Uh.. no. static_assert is a static assert, so its condition has always
been required
to be constexpr, and will remain so. My point was that static_assert
as such in a constexpr function
wasn't "always" allowed. Vittorio's example cannot be supported by static_assert
because a function argument is never a constant expression, so if we want
to support Vittorio's example, we need something else in addition to
static_assert.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 27/09/2014 05:52 p.m., Ville Voutilainen wrote:
> On 27 September 2014 22:51, Agust=C3=ADn K-ballo Berg=C3=A9 <kaballo86@ho=
tmail.com> wrote:
>> static_assert is and always was allowed in a constexpr function. The int=
ent
>
> Not to be pedantic (ha ha), but allowing static_assert in a constexpr fun=
ction
> got into c++11 on the 11th hour just before the final standard draft
> was accepted
> for balloting.

That's a valid remark. I was speaking from a standards point of view, I=20
was not considering proposals nor drafts.

Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 28 September 2014 00:04, Agust=C3=ADn K-ballo Berg=C3=A9 <kaballo86@hotm=
ail.com> wrote:
> On 27/09/2014 05:52 p.m., Ville Voutilainen wrote:
>>
>> On 27 September 2014 22:51, Agust=C3=ADn K-ballo Berg=C3=A9 <kaballo86@h=
otmail.com>
>> wrote:
>>>
>>> static_assert is and always was allowed in a constexpr function. The
>>> intent
>>
>>
>> Not to be pedantic (ha ha), but allowing static_assert in a constexpr
>> function
>> got into c++11 on the 11th hour just before the final standard draft
>> was accepted
>> for balloting.
>
>
> That's a valid remark. I was speaking from a standards point of view, I w=
as
> not considering proposals nor drafts.


Yes, I understand that, but apparently to the world at large the
message hasn't gotten
through that static_assert in a function (template) marked constexpr
is ok. I would
like to emphasize that static_assert does not, and will not, do what
the original
submitter suggests. It is not a "maybe-constexpr"-facility that may or
may not require
a constant expression as its condition, and it shouldn't be mutated into on=
e.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Sep 27, 2014, at 12:42 PM, Vittorio Romeo <vittorio.romeo.vee@gmail.com>=
 wrote:

> Proposal:
> I propose a new standard function/macro/whatever that allows the develope=
r to assert certain predicates in `constexpr` functions.
>=20
> constexpr int getClamped(int mValue, int mMin, int mMax) noexcept
> {
>     // constexpr_assert(<predicate>, <optional message>);
>     constexpr_assert(mMin < mMax, "mMin must be smaller than mMax");
>=20
>     return mValue < mMin ? mMin : ((mValue > mMax) ? mMax : mValue);
> }
>=20
> int main()
> {
>     // "Obvious" compile-time evaluation
>     std::array<int, getClamped(5, 3, 4)> array;
>=20
>     // "Obvious" run-time evaluation
>     int x; std::cin >> x;=20
>     std::cout << getClamped(5, x, 10);
>=20
>     return 0;
> }

This:

#include <array>
#include <iostream>
#include <cassert>

constexpr int getClamped(int mValue, int mMin, int mMax) noexcept
{
    assert(mMin < mMax && "mMin must be smaller than mMax");

    return mValue < mMin ? mMin : ((mValue > mMax) ? mMax : mValue);
}

int main()
{
    // "Obvious" compile-time evaluation
    std::array<int, getClamped(5, 3, 4)> array;

    // "Obvious" run-time evaluation
    int x; std::cin >> x;=20
    std::cout << getClamped(5, x, 10);

    return 0;
}

works for me today, as you intend (or at least close), using:

clang++ -std=3Dc++1y test.cpp

clang++ -v
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

*  If I enter 5, the program runs normally.
*  If I enter 11, the program asserts.
*  If I call getClamped(5, 5, 4) in a non-constexpr context, I get an asser=
t:

const int i =3D getClamped(5, 5, 4);

Assertion failed: (mMin < mMax && "mMin must be smaller than mMax"), functi=
on getClamped, file test.cpp, line 7.

*  If I call getClamped(5, 5, 4) in a constexpr context (as does your examp=
le), I get a compile-time error:

clang++ -std=3Dc++1y test.cpp
test.cpp:15:21: error: non-type template argument is not a constant express=
ion
    std::array<int, getClamped(5, 5, 4)> array;
                    ^~~~~~~~~~~~~~~~~~~
test.cpp:7:5: note: non-constexpr function '__assert_rtn' cannot be used in=
 a constant expression
    assert(mMin < mMax && "mMin must be smaller than mMax");
    ^
/usr/include/assert.h:93:34: note: expanded from macro 'assert'
    (__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __FILE__, __LINE__,=
 #e) : (void)0)
                                 ^
test.cpp:15:21: note: in call to 'getClamped(5, 5, 4)'
    std::array<int, getClamped(5, 5, 4)> array;
                    ^
/usr/include/assert.h:76:6: note: declared here
void __assert_rtn(const char *, const char *, int, const char *) __dead2;
     ^
1 error generated.


I've reviewed the constraints on constexpr functions and there is no wordin=
g which says that constexpr functions can not contain an assert.  But neith=
er is there wording assuring that an assert does work.  It may work on clan=
g simply for fortuitous reasons.  The assert macro (on OS X) preprocesses t=
o:

constexpr int getClamped(int mValue, int mMin, int mMax) noexcept
{
    (__builtin_expect(!(mMin < mMax && "mMin must be smaller than mMax"), 0=
) ? __assert_rtn(__func__, "test.cpp", 7, "mMin < mMax && \"mMin must be sm=
aller than mMax\"") : (void)0);

    return mValue < mMin ? mMin : ((mValue > mMax) ? mMax : mValue);
}

Perhaps your proposal could be simplified to just assuring that assert work=
s as described above for clang.  Such a simplification would likely increas=
e its odds.  And I agree that this is useful behavior to have in one's tool=
box.

Howard

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_9CC6B4D6-8579-4A2E-B310-029DF49A1B29
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-28, at 5:33 AM, Howard Hinnant <howard.hinnant@gmail.com> wrote:

> Perhaps your proposal could be simplified to just assuring that assert wo=
rks as described above for clang.  Such a simplification would likely incre=
ase its odds.  And I agree that this is useful behavior to have in one's to=
olbox.

Regular assert does nothing when the condition is true, and all bets are of=
f if it's false, so why should there be a problem?

The StackOverflow question is simply reflecting lack of relaxed constexpr i=
n C++11 and GCC 4.8.1. Relaxed assert is newly implemented in 4.10. The err=
or is "error: body of constexpr function ... not a return-statement", not "=
assert is never a constant-expression."

Nevertheless, it should work using a comma instead of a semicolon. Clang ac=
cepts this in C++11 mode, but GCC does not, which looks like a bug.

     return assert(mMin < mMax),
     mValue < mMin ? mMin : (mValue > mMax ? mMax : mValue);

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_9CC6B4D6-8579-4A2E-B310-029DF49A1B29
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09&ndash;28, at 5:33 AM, Howard Hinnant &lt;<a href=3D"mailto:howard.=
hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span style=3D"fon=
t-family: Helvetica; font-size: 12px; font-style: normal; font-variant: nor=
mal; font-weight: normal; letter-spacing: normal; line-height: normal; orph=
ans: auto; text-align: start; text-indent: 0px; text-transform: none; white=
-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width:=
 0px; float: none; display: inline !important;">Perhaps your proposal could=
 be simplified to just assuring that assert works as described above for cl=
ang. &nbsp;Such a simplification would likely increase its odds. &nbsp;And =
I agree that this is useful behavior to have in one's toolbox.</span><br st=
yle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-va=
riant: normal; font-weight: normal; letter-spacing: normal; line-height: no=
rmal; orphans: auto; text-align: start; text-indent: 0px; text-transform: n=
one; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-str=
oke-width: 0px;"></blockquote></div><br><div>Regular <font face=3D"Courier"=
>assert</font> does nothing when the condition is true, and all bets are of=
f if it&rsquo;s false, so why should there be a problem?</div><div><br></di=
v><div>The StackOverflow question is simply reflecting lack of relaxed cons=
texpr in C++11 and GCC 4.8.1. Relaxed assert is newly implemented in 4.10. =
The error is "<em>error</em>: body of constexpr function &hellip; not a ret=
urn-statement<strong>&rdquo;</strong>, not &ldquo;assert is never a constan=
t-expression.&rdquo;</div><div><br></div><div>Nevertheless, it should work =
using a comma instead of a semicolon. Clang accepts this in C++11 mode, but=
 GCC does not, which looks like a bug.</div><div><br></div><div><font face=
=3D"Courier">&nbsp; &nbsp; &nbsp;return assert(mMin &lt; mMax),<br>&nbsp; &=
nbsp; &nbsp;mValue &lt; mMin ? mMin : (mValue &gt; mMax ? mMax : mValue);<b=
r></font></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_9CC6B4D6-8579-4A2E-B310-029DF49A1B29--

.

------=_Part_1786_1588166426.1411857537284
Content-Type: text/plain; charset=UTF-8

Just found this related
article: http://ericniebler.com/2014/09/27/assert-and-constexpr-in-cxx11/

Kind regards,

Andy

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1786_1588166426.1411857537284
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><font face="arial, sans-serif" size="2">Just found this related article:&nbsp;http://ericniebler.com/2014/09/27/assert-and-constexpr-in-cxx11/<br><br>Kind regards,<br><br>Andy</font></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_1786_1588166426.1411857537284--

.

On 9/27/2014 11:42 AM, Vittorio Romeo wrote:
> Problem:
> Using assertions in a `constexpr` function is currently not possible in
> C++14.
> As `constexpr` is used more and more, it has become a necessity (at
> least for me) to have a tool that allows me to perform debug checks on
> `constexpr` functions.
>
> Currently, there are no elegant or obvious ways to replicate the
> behavior of assertions in `constexpr` functions.
> http://stackoverflow.com/questions/26072709/alternative-to-asserts-for-constexpr-functions
> http://stackoverflow.com/questions/18648069/g-doesnt-compile-constexpr-function-with-assert-in-it/

I assume the goal here is to produce a compilation failure if you
violate some preconditions in a constexpr function? If so, you can just
throw an exception if the precondition isn't met:

constexpr int foo(int x) {
   if(x < 0)
     throw std::invalid_argument("x must be >= 0");
   return x;
}

I know it's not exactly the same as assert(), but it might meet your
needs anyway.

- Jim

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Sep 27, 2014, at 6:29 PM, David Krauss <potswa@gmail.com> wrote:

>=20
> On 2014-09-28, at 5:33 AM, Howard Hinnant <howard.hinnant@gmail.com> wrot=
e:
>=20
>> Perhaps your proposal could be simplified to just assuring that assert w=
orks as described above for clang.  Such a simplification would likely incr=
ease its odds.  And I agree that this is useful behavior to have in one's t=
oolbox.
>=20
> Regular assert does nothing when the condition is true, and all bets are =
off if it's false, so why should there be a problem?
>=20
> The StackOverflow question is simply reflecting lack of relaxed constexpr=
 in C++11 and GCC 4.8.1. Relaxed assert is newly implemented in 4.10. The e=
rror is "error: body of constexpr function ... not a return-statement", not=
 "assert is never a constant-expression."

In C++14 the body of constexpr function need not be essentially just a retu=
rn statement.  See http://isocpp.org/files/papers/N3652.html .  That error =
from 4.10 sounds suspiciously like N3652 has not yet been fully implemented=
..

Howard

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

I was going to mention throw, but then saw Jim's message with the same thin=
g =3D).  Why don't we just modify the Standard as follows?:

1. throw would now be legal in a constexpr function ordinary statement (not=
 enums and such) but not other constant-expressions.  This is a required ch=
ange if we want to allow this, because there is no conditional expression:

constexpr void abort_compile()
{
    throw "something bad happened";
}

2. If evaluated at compile time, throw causes the top-level constexpr to be=
come ill-formed, and a diagnostic is produced.  Since try is not allowed, e=
xceptions will propagate all the way up until the top-level constexpr funct=
ion.

3. The compiler diagnostic would be required to have the name of the type t=
hrown, unless it was (possibly const-qualified) char *, wchar_t *, char16_t=
 *, char32_t *, char (&)[X], wchar_t (&)[X], char16_t (&)[X] or char32_t (&=
)[X].  In those cases, it the diagnostic would include the printable conten=
ts of the string, with unspecified behavior for nonprintable characters and=
 characters not representable in the character set used by the implementati=
on's diagnostic messages.

Melissa

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 2014-09-28, at 7:14 AM, Howard Hinnant <howard.hinnant@gmail.com> wrote:

> In C++14 the body of constexpr function need not be essentially just a return statement.  See http://isocpp.org/files/papers/N3652.html .  That error from 4.10 sounds suspiciously like N3652 has not yet been fully implemented.

Nobody mentioned an error from GCC 4.10. I'm aware of relaxed constexpr; with a little luck I'll have a paper advocating friendly numeric policies for it at Urbana.

I'm confused that so many people expect throw to be different from assert. Both are void expressions, the only difference is that the ternary operator has special handling of throw-expressions. But, the comma operator doesn't.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_1521_1644597657.1411860426534
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, September 27, 2014 8:20:32 PM UTC-3, David Krauss wrote:
>
> I=E2=80=99m confused that so many people expect throw to be different fro=
m assert.=20
> Both are void expressions, the only difference is that the ternary operat=
or=20
> has special handling of throw-expressions. But, the comma operator doesn=
=E2=80=99t.=20
>

There is one small problem that should be addressed first thought,=20
currently constexpr functions returning void are not allowed.
So declaring a constexpr assert function would be illegal if that's not=20
relaxed.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1521_1644597657.1411860426534
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, September 27, 2014 8:20:32 PM UTC-3, David Kr=
auss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
I=E2=80=99m confused that so many people expect throw to be different from =
assert. Both are void expressions, the only difference is that the ternary =
operator has special handling of throw-expressions. But, the comma operator=
 doesn=E2=80=99t.
<br></blockquote><div><br>There is one small problem that should be address=
ed first thought, currently constexpr functions returning void are not allo=
wed.<br>So declaring a constexpr assert function would be illegal if that's=
 not relaxed.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1521_1644597657.1411860426534--

.

On Sep 27, 2014, at 7:20 PM, David Krauss <potswa@gmail.com> wrote:

>=20
> On 2014-09-28, at 7:14 AM, Howard Hinnant <howard.hinnant@gmail.com> wrot=
e:
>=20
>> In C++14 the body of constexpr function need not be essentially just a r=
eturn statement.  See http://isocpp.org/files/papers/N3652.html .  That err=
or from 4.10 sounds suspiciously like N3652 has not yet been fully implemen=
ted.
>=20
> Nobody mentioned an error from GCC 4.10.

Sorry, I misread your message.

> I'm aware of relaxed constexpr; with a little luck I'll have a paper advo=
cating friendly numeric policies for it at Urbana.

I look forward to reading it.

>=20
> I'm confused that so many people expect throw to be different from assert=
.. Both are void expressions, the only difference is that the ternary operat=
or has special handling of throw-expressions. But, the comma operator doesn=
't.

I believe the example that started this thread, should just work with asser=
t:

constexpr int getClamped(int mValue, int mMin, int mMax) noexcept
{
    assert(mMin < mMax && "mMin must be smaller than mMax");

    return mValue < mMin ? mMin : ((mValue > mMax) ? mMax : mValue);
}

but I don't think that the assert macro is currently sufficiently constrain=
ed by the standard to guarantee that it will work (it should just work in p=
ractice though).  For example the assert macro is allowed to contain a goto=
 statement which is currently not allowed in a constexpr function.

Howard

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 2014-09-28, at 7:27 AM, Howard Hinnant <howard.hinnant@gmail.com> wrote:

> I don't think that the assert macro is currently sufficiently constrained=
 by the standard to guarantee that it will work (it should just work in pra=
ctice though).  For example the assert macro is allowed to contain a goto s=
tatement which is currently not allowed in a constexpr function.

The goto could only be inside a lambda since it expands to an expression, a=
nd lambdas aren't allowed, so that's perhaps more to the point. But that's =
contrived.


On 2014-09-28, at 7:27 AM, Matheus Izvekov <mizvekov@gmail.com> wrote:

> There is one small problem that should be addressed first thought, curren=
tly constexpr functions returning void are not allowed.
> So declaring a constexpr assert function would be illegal if that's not r=
elaxed.

assert is a macro, not a function. In GCC, its value is obtained from a ter=
nary expression with two void operands. Most platforms avoid any function c=
all in the non-asserting case.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--089e014940526d82b6050414e435
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 27, 2014 at 4:27 PM, Matheus Izvekov <mizvekov@gmail.com> wrote=
:

> On Saturday, September 27, 2014 8:20:32 PM UTC-3, David Krauss wrote:
>>
>> I=E2=80=99m confused that so many people expect throw to be different fr=
om
>> assert. Both are void expressions, the only difference is that the terna=
ry
>> operator has special handling of throw-expressions. But, the comma opera=
tor
>> doesn=E2=80=99t.
>>
>
> There is one small problem that should be addressed first thought,
> currently constexpr functions returning void are not allowed.
>

Yes, they are, in C++14 onwards.

Also, take a look at:

http://cplusplus.github.io/LWG/lwg-active.html#2234

.... which is attempting to guarantee that assert works properly within a
constant expression.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--089e014940526d82b6050414e435
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Sep 27, 2014 at 4:27 PM, Matheus Izvekov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mizvekov@gmail.com" target=3D"_blank">mizvekov@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Sat=
urday, September 27, 2014 8:20:32 PM UTC-3, David Krauss wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex">
I=E2=80=99m confused that so many people expect throw to be different from =
assert. Both are void expressions, the only difference is that the ternary =
operator has special handling of throw-expressions. But, the comma operator=
 doesn=E2=80=99t.
<br></blockquote></span><div><br>There is one small problem that should be =
addressed first thought, currently constexpr functions returning void are n=
ot allowed.<br></div></div></blockquote><div><br></div><div>Yes, they are, =
in C++14 onwards.</div><div><br></div><div>Also, take a look at:</div><div>=
<br></div><div><a href=3D"http://cplusplus.github.io/LWG/lwg-active.html#22=
34">http://cplusplus.github.io/LWG/lwg-active.html#2234</a><br></div><div><=
br></div><div>... which is attempting to guarantee that assert works proper=
ly within a constant expression.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e014940526d82b6050414e435--

.

On Sep 27, 2014, at 7:27 PM, Matheus Izvekov <mizvekov@gmail.com> wrote:

> On Saturday, September 27, 2014 8:20:32 PM UTC-3, David Krauss wrote:
> I'm confused that so many people expect throw to be different from assert. Both are void expressions, the only difference is that the ternary operator has special handling of throw-expressions. But, the comma operator doesn't.
>
> There is one small problem that should be addressed first thought, currently constexpr functions returning void are not allowed.
> So declaring a constexpr assert function would be illegal if that's not relaxed.

In C++14 constepxr functions can call non-constxpr functions, as long as they don't do so at compile time.  I.e. this is legal:

void
non_constexpr_func(int&);

constexpr
int
constexpr_func(int x)
{
    if (x <= 0)
        non_constexpr_func(x);
    return x;
}

int
main()
{
    constexpr int i = constexpr_func(1);
}

void
non_constexpr_func(int&)
{
}

If main changes to

    const int i = constexpr_func(0);

it is still legal, but i will be computed at run time.

If main changes to:

    constexpr int i = constexpr_func(0);

then you get a compile-time error.

test.cpp:16:19: error: constexpr variable 'i' must be initialized by a constant expression
    constexpr int i = constexpr_func(0);
                  ^   ~~~~~~~~~~~~~~~~~
test.cpp:9:9: note: non-constexpr function 'non_constexpr_func' cannot be used in a constant expression
        non_constexpr_func(x);
        ^
test.cpp:16:23: note: in call to 'constexpr_func(0)'
    constexpr int i = constexpr_func(0);
                      ^
test.cpp:2:1: note: declared here
non_constexpr_func(int&);
^
1 error generated.

Howard

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Sep 27, 2014, at 8:04 PM, Richard Smith <richard@metafoo.co.uk> wrote:

> Also, take a look at:
>
> http://cplusplus.github.io/LWG/lwg-active.html#2234
>

Thanks Richard!

You have to get up pretty early to stay ahead of Daniel... :-)

Howard

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_1394_466995440.1411863258016
Content-Type: text/plain; charset=UTF-8

On Saturday, September 27, 2014 9:02:41 PM UTC-3, David Krauss wrote:
>
> assert is a macro, not a function. In GCC, its value is obtained from a
> ternary expression with two void operands. Most platforms avoid any
> function call in the non-asserting case.
>

Right, but it would eventually come up that it would be desirable to wrap
an alternative version into a function, instead of a macro, to solve the
side-effects issue.
But as Richard pointed out below, that seems not to be an issue anymore
with C++14.

On Saturday, September 27, 2014 9:04:26 PM UTC-3, Richard Smith wrote:

> Yes, they are, in C++14 onwards.
>
> Also, take a look at:
>
> http://cplusplus.github.io/LWG/lwg-active.html#2234
>
> ... which is attempting to guarantee that assert works properly within a
> constant expression.
>

Great, so it seems the issue is already being taken care of, thanks!

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1394_466995440.1411863258016
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, September 27, 2014 9:02:41 PM UTC-3, David Kr=
auss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
assert is a macro, not a function. In GCC, its value is obtained from a ter=
nary expression with two void operands. Most platforms avoid any function c=
all in the non-asserting case.
<br></blockquote><div><br>Right, but it would eventually come up that it wo=
uld be desirable to wrap an alternative version into a function, instead of=
 a macro, to solve the side-effects issue.<br>But as Richard pointed out be=
low, that seems not to be an issue anymore with C++14.<br><br>On Saturday, =
September 27, 2014 9:04:26 PM UTC-3, Richard Smith wrote:<br><blockquote st=
yle=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204)=
; padding-left: 1ex;" class=3D"gmail_quote"><div>Yes, they are, in C++14 on=
wards.</div><div><br></div><div>Also, take a look at:</div><div><br></div><=
div><a href=3D"http://cplusplus.github.io/LWG/lwg-active.html#2234" target=
=3D"_blank">http://cplusplus.github.io/<wbr>LWG/lwg-active.html#2234</a><br=
></div><div><br></div><div>... which is attempting to guarantee that assert=
 works properly within a constant expression.</div></blockquote><div><br>Gr=
eat, so it seems the issue is already being taken care of, thanks!<br></div=
></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1394_466995440.1411863258016--

.

On 2014-09-28, at 8:14 AM, Matheus Izvekov <mizvekov@gmail.com> wrote:

> Right, but it would eventually come up that it would be desirable to wrap=
 an alternative version into a function, instead of a macro, to solve the s=
ide-effects issue.
> But as Richard pointed out below, that seems not to be an issue anymore w=
ith C++14.

There never was a side-effects issue, even in C++11. Assert has no side-eff=
ects if the condition is true. Since there never was a problem in the first=
 place, aside from a GCC bug where certain intrinsic functions render the r=
eturn statement "not a return statement," there's no need per the standard =
for an alternative to anything.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_1479_1439663716.1411866338941
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, September 27, 2014 10:00:00 PM UTC-3, David Krauss wrote:
>
> There never was a side-effects issue, even in C++11. Assert has no=20
> side-effects if the condition is true. Since there never was a problem in=
=20
> the first place, aside from a GCC bug where certain intrinsic functions=
=20
> render the return statement =E2=80=9Cnot a return statement,=E2=80=9D the=
re=E2=80=99s no need per=20
> the standard for an alternative to anything.=20
>

Right, but maybe it should, for consistency with ordinary function calls?=
=20

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1479_1439663716.1411866338941
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, September 27, 2014 10:00:00 PM UTC-3, David K=
rauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
There never was a side-effects issue, even in C++11. Assert has no side-eff=
ects if the condition is true. Since there never was a problem in the first=
 place, aside from a GCC bug where certain intrinsic functions render the r=
eturn statement =E2=80=9Cnot a return statement,=E2=80=9D there=E2=80=99s n=
o need per the standard for an alternative to anything.
<br></blockquote><div><br>Right, but maybe it should, for consistency with =
ordinary function calls? <br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1479_1439663716.1411866338941--

.

------=_Part_1562_1264872737.1411867625672
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, September 27, 2014 10:00:00 PM UTC-3, David Krauss wrote:
>
> There never was a side-effects issue, even in C++11. Assert has no=20
> side-effects if the condition is true. Since there never was a problem in=
=20
> the first place, aside from a GCC bug where certain intrinsic functions=
=20
> render the return statement =E2=80=9Cnot a return statement,=E2=80=9D the=
re=E2=80=99s no need per=20
> the standard for an alternative to anything.=20
>

Oh I think I know why we are miscommunicating, I am referring to the=20
possible side effects of the evaluation of the condition, not of any=20
side-effects of the assert "body".

I think it would be useful if there was something from the c++ standard on=
=20
top of the plain assert from <cassert>.
This would make it possible to put this function inside a namespace, and=20
another possible addition
this could facilitate is that it could be specified that the program is=20
ill-formed if the condition is false, even if debugging is disabled.

This could be a way to sneak in MSVC's __asume and the equivalent which can=
=20
be written in gcc/clang with builtin_unreachable.
So assert would also be a way to give compilers hints about what conditions=
=20
can be true in a program, and it would help optimize the code also when=20
debugging is disabled.
Supporting these hints would be optional of course.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1562_1264872737.1411867625672
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, September 27, 2014 10:00:00 PM UTC-3, David K=
rauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
There never was a side-effects issue, even in C++11. Assert has no side-eff=
ects if the condition is true. Since there never was a problem in the first=
 place, aside from a GCC bug where certain intrinsic functions render the r=
eturn statement =E2=80=9Cnot a return statement,=E2=80=9D there=E2=80=99s n=
o need per the standard for an alternative to anything.
<br></blockquote><div><br>Oh I think I know why we are miscommunicating, I =
am referring to the possible side effects of the evaluation of the conditio=
n, not of any side-effects of the assert "body".<br><br>I think it would be=
 useful if there was something from the c++ standard on top of the plain as=
sert from &lt;cassert&gt;.<br>This would make it possible to put this funct=
ion inside a namespace, and another possible addition<br>this could facilit=
ate is that it could be specified that the program is ill-formed if the con=
dition is false, even if debugging is disabled.<br><br>This could be a way =
to sneak in MSVC's __asume and the equivalent which can be written in gcc/c=
lang with builtin_unreachable.<br>So assert would also be a way to give com=
pilers hints about what conditions can be true in a program, and it would h=
elp optimize the code also when debugging is disabled.<br>Supporting these =
hints would be optional of course.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1562_1264872737.1411867625672--

.

--Apple-Mail=_96CEF7C6-3004-442F-9CE5-BD8F62283727
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-28, at 9:27 AM, Matheus Izvekov <mizvekov@gmail.com> wrote:

> Oh I think I know why we are miscommunicating, I am referring to the poss=
ible side effects of the evaluation of the condition, not of any side-effec=
ts of the assert "body".
>=20
> I think it would be useful if there was something from the c++ standard o=
n top of the plain assert from <cassert>.
> This would make it possible to put this function inside a namespace, and =
another possible addition
> this could facilitate is that it could be specified that the program is i=
ll-formed if the condition is false, even if debugging is disabled.

I don't think most users wants an assert which evaluates its condition when=
 debugging is disabled.

> This could be a way to sneak in MSVC's __asume and the equivalent which c=
an be written in gcc/clang with builtin_unreachable.

The builtin_unreachable method may evaluate the expression, particularly if=
 it uses the short-circuit operators &&, ||, ?:, ",".

The problem with assert is that it's too weird. Since we already have stati=
c_assert declarations in the core language, the best solution might be simp=
ly to promote it to a full-on operator. Since using the assert macro with t=
he comma operator like assert(cond, "error") is ill-formed in the preproces=
sor and would be nonsense anyway, such an operator could be given the same =
syntax as the static_assert declaration. As for NDEBUG, we could require <c=
assert> to say,

#ifdef NDEBUG
#define assert(x) ((void)0)
#elif __cplusplus
#define assert(...) assert(__VA_ARGS__) // it's an operator now
#endif

And then, the desire to qualify it with std:: goes away.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_96CEF7C6-3004-442F-9CE5-BD8F62283727
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09&ndash;28, at 9:27 AM, Matheus Izvekov &lt;<a href=3D"mailto:mizvek=
ov@gmail.com">mizvekov@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-int=
erchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div>Oh I thin=
k I know why we are miscommunicating, I am referring to the possible side e=
ffects of the evaluation of the condition, not of any side-effects of the a=
ssert "body".<br><br>I think it would be useful if there was something from=
 the c++ standard on top of the plain assert from &lt;cassert&gt;.<br>This =
would make it possible to put this function inside a namespace, and another=
 possible addition<br>this could facilitate is that it could be specified t=
hat the program is ill-formed if the condition is false, even if debugging =
is disabled.<br></div></div></blockquote><div><br></div><div>I don&rsquo;t =
think most users wants an <font face=3D"Courier">assert</font> which evalua=
tes its condition when debugging is disabled.</div><div><br></div><blockquo=
te type=3D"cite"><div dir=3D"ltr"><div>This could be a way to sneak in MSVC=
's __asume and the equivalent which can be written in gcc/clang with builti=
n_unreachable.<br></div></div></blockquote><div><br></div><div>The <font fa=
ce=3D"Courier">builtin_unreachable</font> method may evaluate the expressio=
n, particularly if it uses the short-circuit operators <font face=3D"Courie=
r">&amp;&amp;</font>, <font face=3D"Courier">||</font>, <font face=3D"Couri=
er">?:</font>, &ldquo;<font face=3D"Courier">,</font>&rdquo;.</div><div><br=
></div><div>The problem with <font face=3D"Courier">assert</font> is that i=
t&rsquo;s too weird. Since we already have <font face=3D"Courier">static_as=
sert</font> declarations in the core language, the best solution might be s=
imply to promote it to a full-on operator. Since using the <font face=3D"Co=
urier">assert</font> macro with the comma operator like <font face=3D"Couri=
er">assert(cond, "error"</font><font face=3D"Courier">)</font> is ill-forme=
d in the preprocessor and would be nonsense anyway, such an operator could =
be given the same syntax as the <font face=3D"Courier">static_assert</font>=
 declaration. As for <font face=3D"Courier">NDEBUG</font>, we could require=
 <font face=3D"Courier">&lt;cassert&gt;</font> to say,</div><div><br></div>=
<div><font face=3D"Courier">#ifdef NDEBUG</font></div><div><font face=3D"Co=
urier">#define assert(x) ((void)0)</font></div><div><font face=3D"Courier">=
#elif __cplusplus</font></div><div><font face=3D"Courier">#define assert(..=
..) assert(__VA_ARGS__) // it&rsquo;s an operator now</font></div><div><font=
 face=3D"Courier">#endif</font></div><div><br></div><div>And then, the desi=
re to qualify it with <font face=3D"Courier">std::</font> goes away.</div><=
div><br></div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_96CEF7C6-3004-442F-9CE5-BD8F62283727--

.

--Apple-Mail=_F8B11317-20E6-469C-B118-0BF6C7982240
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-28, at 9:44 AM, David Krauss <potswa@gmail.com> wrote:

> #define assert(...) assert(__VA_ARGS__) // it's an operator now

Uck, I'm a bit ill today. Obviously the better specification is to say that <assert.h> shall not define the macro assert unless NDEBUG is 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--Apple-Mail=_F8B11317-20E6-469C-B118-0BF6C7982240
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09&ndash;28, at 9:44 AM, David Krauss &lt;<a href=3D"mailto:potswa@gm=
ail.com">potswa@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchang=
e-newline"><blockquote type=3D"cite"><meta http-equiv=3D"Content-Type" cont=
ent=3D"text/html charset=3Dwindows-1252"><div style=3D"word-wrap: break-wor=
d; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><=
div><font face=3D"Courier">#define assert(...) assert(__VA_ARGS__) // it&rs=
quo;s an operator now</font></div></div></div></blockquote><br></div><div>U=
ck, I&rsquo;m a bit ill today. Obviously the better specification is to say=
 that <font face=3D"Courier">&lt;assert.h&gt;</font> shall not define the m=
acro <font face=3D"Courier">assert</font> unless <font face=3D"Courier">NDE=
BUG</font> is defined.</div><div><br></div><br></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_F8B11317-20E6-469C-B118-0BF6C7982240--

.

On Saturday 27 September 2014 18:27:05 Matheus Izvekov wrote:
> This could be a way to sneak in MSVC's __asume and the equivalent which can
> be written in gcc/clang with builtin_unreachable.
> So assert would also be a way to give compilers hints about what conditions
> can be true in a program, and it would help optimize the code also when
> debugging is disabled.
> Supporting these hints would be optional of course.

I ran into that problem with Qt.

I wanted to make Q_ASSERT be Q_ASSUME in release builds, so the hints for
optimisation remained. Unfortunately, that meant the side-effects would always
be present, which is not always wanted, and GCC and Clang sometimes leave
unnecessary checks instead in the code.

That's different from the MSVC behaviour in which __assume never has side-
effects. It simply serves as a hint that the particular expression is true.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_1357_1799244738.1411869548490
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, September 27, 2014 10:44:48 PM UTC-3, David Krauss wrote:
>
> I don=E2=80=99t think most users wants an assert which evaluates its cond=
ition=20
> when debugging is disabled.
>

Well, it might be desirable because it simplifies things, using assert=20
looks like a function call, and if it also mostly behaves like one, then it=
=20
will also eliminate a common surprise.
But I would also understand if the general opinion is that assert should=20
never have its condition expression have side-effects.
=20

> The problem with assert is that it=E2=80=99s too weird. Since we already =
have=20
> static_assert declarations in the core language, the best solution might=
=20
> be simply to promote it to a full-on operator. Since using the assert=20
> macro with the comma operator like assert(cond, "error") is ill-formed in=
=20
> the preprocessor and would be nonsense anyway, such an operator could be=
=20
> given the same syntax as the static_assert declaration. As for NDEBUG, we=
=20
> could require <cassert> to say,
>

That looks good, not opposed to it being an operator.
An operator would be even better if the desire is for no side effects on=20
the condition.

But I think a solution should be proposed where the "ill-formed if false=20
even in nodebug" holds, so that the optimization can still be performed.

I suppose such optimization could be a great way to convince more people to=
=20
write asserts.
Big headline: "Write asserts and your code gets faster too!"

So even in case people would be wasting their time micro-optimizing, they=
=20
would be also doing something more valuable like documenting their program=
=20
invariants.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1357_1799244738.1411869548490
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, September 27, 2014 10:44:48 PM UTC-3, David K=
rauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word=
-wrap:break-word"><div><div></div><div>I don=E2=80=99t think most users wan=
ts an <font face=3D"Courier">assert</font> which evaluates its condition wh=
en debugging is disabled.</div></div></div></blockquote><div><br>Well, it m=
ight be desirable because it simplifies things, using assert looks like a f=
unction call, and if it also mostly behaves like one, then it will also eli=
minate a common surprise.<br>But I would also understand if the general opi=
nion is that assert should never have its condition expression have side-ef=
fects.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div sty=
le=3D"word-wrap:break-word"><div><div>The problem with <font face=3D"Courie=
r">assert</font> is that it=E2=80=99s too weird. Since we already have <fon=
t face=3D"Courier">static_assert</font> declarations in the core language, =
the best solution might be simply to promote it to a full-on operator. Sinc=
e using the <font face=3D"Courier">assert</font> macro with the comma opera=
tor like <font face=3D"Courier">assert(cond, "error"</font><font face=3D"Co=
urier">)</font> is ill-formed in the preprocessor and would be nonsense any=
way, such an operator could be given the same syntax as the <font face=3D"C=
ourier">static_assert</font> declaration. As for <font face=3D"Courier">NDE=
BUG</font>, we could require <font face=3D"Courier">&lt;cassert&gt;</font> =
to say,</div></div></div></blockquote><div><br>That looks good, not opposed=
 to it being an operator.<br>An operator would be even better if the desire=
 is for no side effects on the condition.<br><br>But I think a solution sho=
uld be proposed where the "ill-formed if false even in nodebug" holds, so t=
hat the optimization can still be performed.<br><br>I suppose such optimiza=
tion could be a great way to convince more people to write asserts.<br>Big =
headline: "Write asserts and your code gets faster too!"<br><br>So even in =
case people would be wasting their time micro-optimizing, they would be als=
o doing something more valuable like documenting their program invariants.<=
br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1357_1799244738.1411869548490--

.

------=_Part_1572_1399203434.1411869659931
Content-Type: text/plain; charset=UTF-8

On Saturday, September 27, 2014 10:52:42 PM UTC-3, Thiago Macieira wrote:
>
> I wanted to make Q_ASSERT be Q_ASSUME in release builds, so the hints for
> optimisation remained. Unfortunately, that meant the side-effects would
> always
> be present, which is not always wanted, and GCC and Clang sometimes leave
> unnecessary checks instead in the code.
>
> That's different from the MSVC behaviour in which __assume never has side-
> effects. It simply serves as a hint that the particular expression is
> true.
>

I see. If the desire is for no side-effects, then an operator like David
proposed would be great, it would be much easier to avoid them from an
implementation POV.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1572_1399203434.1411869659931
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, September 27, 2014 10:52:42 PM UTC-3, Thiago =
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I wanted to mak=
e Q_ASSERT be Q_ASSUME in release builds, so the hints for=20
<br>optimisation remained. Unfortunately, that meant the side-effects would=
 always=20
<br>be present, which is not always wanted, and GCC and Clang sometimes lea=
ve=20
<br>unnecessary checks instead in the code.
<br>
<br>That's different from the MSVC behaviour in which __assume never has si=
de-
<br>effects. It simply serves as a hint that the particular expression is t=
rue.
<br></blockquote><div><br>I see. If the desire is for no side-effects, then=
 an operator like David proposed would be great, it would be much easier to=
 avoid them from an implementation POV. <br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1572_1399203434.1411869659931--

.

On 28 September 2014 01:29, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9309=E2=80=9328, at 5:33 AM, Howard Hinnant <howard.hinnant=
@gmail.com> wrote:
>
> Perhaps your proposal could be simplified to just assuring that assert wo=
rks
> as described above for clang.  Such a simplification would likely increas=
e
> its odds.  And I agree that this is useful behavior to have in one's
> toolbox.
>
>
> Regular assert does nothing when the condition is true, and all bets are =
off
> if it=E2=80=99s false, so why should there be a problem?
>
> The StackOverflow question is simply reflecting lack of relaxed constexpr=
 in
> C++11 and GCC 4.8.1. Relaxed assert is newly implemented in 4.10. The err=
or
> is "error: body of constexpr function =E2=80=A6 not a return-statement=E2=
=80=9D, not =E2=80=9Cassert
> is never a constant-expression.=E2=80=9D
>
> Nevertheless, it should work using a comma instead of a semicolon. Clang
> accepts this in C++11 mode, but GCC does not, which looks like a bug.
>
>      return assert(mMin < mMax),
>      mValue < mMin ? mMin : (mValue > mMax ? mMax : mValue);

Do note that the "all bets are off" is a problem. [dcl.constexpr]/5 says
"For a non-template, non-defaulted constexpr function or a
non-template, non-defaulted, non-inheriting
constexpr constructor, if no argument values exist such that an
invocation of the function or constructor
could be an evaluated subexpression of a core constant expression
(5.19), the program is ill-formed; no
diagnostic required. "

so if your assert happens to result in code that is never constexpr,
you have an ill-formed
program. I suppose that should be clarified in order to be able to
sanely use asserts
in constexpr functions.

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 28 September 2014 11:54, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> so if your assert happens to result in code that is never constexpr,
> you have an ill-formed
> program. I suppose that should be clarified in order to be able to
> sanely use asserts
> in constexpr functions.

And yes, I should read the whole thread, LWG 2234 is tacking exactly this
problem.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_2301_1598162847.1411927220937
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Isn't this opposite that `constexpr` should do? Standard relay allow this=
=20
or this is only bug in compiler?

On Sunday, September 28, 2014 2:07:14 AM UTC+2, Howard Hinnant wrote:
>
> On Sep 27, 2014, at 7:27 PM, Matheus Izvekov <mizv...@gmail.com=20
> <javascript:>> wrote:=20
>
> > On Saturday, September 27, 2014 8:20:32 PM UTC-3, David Krauss wrote:=
=20
> > I=E2=80=99m confused that so many people expect throw to be different f=
rom=20
> assert. Both are void expressions, the only difference is that the ternar=
y=20
> operator has special handling of throw-expressions. But, the comma operat=
or=20
> doesn=E2=80=99t.=20
> >=20
> > There is one small problem that should be addressed first thought,=20
> currently constexpr functions returning void are not allowed.=20
> > So declaring a constexpr assert function would be illegal if that's not=
=20
> relaxed.=20
>
> In C++14 constepxr functions can call non-constxpr functions, as long as=
=20
> they don=E2=80=99t do so at compile time.  I.e. this is legal:=20
>
> void=20
> non_constexpr_func(int&);=20
>
> constexpr=20
> int=20
> constexpr_func(int x)=20
> {=20
>     if (x <=3D 0)=20
>         non_constexpr_func(x);=20
>     return x;=20
> }=20
>
> int=20
> main()=20
> {=20
>     constexpr int i =3D constexpr_func(1);=20
> }=20
>
> void=20
> non_constexpr_func(int&)=20
> {=20
> }=20
>
> If main changes to=20
>
>     const int i =3D constexpr_func(0);=20
>
> it is still legal, but i will be computed at run time.=20
>
> If main changes to:=20
>
>     constexpr int i =3D constexpr_func(0);=20
>
> then you get a compile-time error.=20
>
> test.cpp:16:19: error: constexpr variable 'i' must be initialized by a=20
> constant expression=20
>     constexpr int i =3D constexpr_func(0);=20
>                   ^   ~~~~~~~~~~~~~~~~~=20
> test.cpp:9:9: note: non-constexpr function 'non_constexpr_func' cannot be=
=20
> used in a constant expression=20
>         non_constexpr_func(x);=20
>         ^=20
> test.cpp:16:23: note: in call to 'constexpr_func(0)'=20
>     constexpr int i =3D constexpr_func(0);=20
>                       ^=20
> test.cpp:2:1: note: declared here=20
> non_constexpr_func(int&);=20
> ^=20
> 1 error generated.=20
>
> Howard=20
>
>

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_2301_1598162847.1411927220937
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Isn't this opposite that `constexpr` should do? Standard r=
elay allow this or this is only bug in compiler?<br><br>On Sunday, Septembe=
r 28, 2014 2:07:14 AM UTC+2, Howard Hinnant wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">On Sep 27, 2014, at 7:27 PM, Matheus Izvekov &lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"V54KYJqTqqQJ" =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">mizv...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; On Saturday, September 27, 2014 8:20:32 PM UTC-3, David Krauss wro=
te:
<br>&gt; I=E2=80=99m confused that so many people expect throw to be differ=
ent from assert. Both are void expressions, the only difference is that the=
 ternary operator has special handling of throw-expressions. But, the comma=
 operator doesn=E2=80=99t.=20
<br>&gt;=20
<br>&gt; There is one small problem that should be addressed first thought,=
 currently constexpr functions returning void are not allowed.
<br>&gt; So declaring a constexpr assert function would be illegal if that'=
s not relaxed.
<br>
<br>In C++14 constepxr functions can call non-constxpr functions, as long a=
s they don=E2=80=99t do so at compile time. &nbsp;I.e. this is legal:
<br>
<br>void
<br>non_constexpr_func(int&amp;);
<br>
<br>constexpr
<br>int
<br>constexpr_func(int x)
<br>{
<br>&nbsp; &nbsp; if (x &lt;=3D 0)
<br>&nbsp; &nbsp; &nbsp; &nbsp; non_constexpr_func(x);
<br>&nbsp; &nbsp; return x;
<br>}
<br>
<br>int
<br>main()
<br>{
<br>&nbsp; &nbsp; constexpr int i =3D constexpr_func(1);
<br>}
<br>
<br>void
<br>non_constexpr_func(int&amp;)
<br>{
<br>}
<br>
<br>If main changes to
<br>
<br>&nbsp; &nbsp; const int i =3D constexpr_func(0);
<br>
<br>it is still legal, but i will be computed at run time.
<br>
<br>If main changes to:
<br>
<br>&nbsp; &nbsp; constexpr int i =3D constexpr_func(0);
<br>
<br>then you get a compile-time error.
<br>
<br>test.cpp:16:19: error: constexpr variable 'i' must be initialized by a =
constant expression
<br>&nbsp; &nbsp; constexpr int i =3D constexpr_func(0);
<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^ &nbsp;=
 ~~~~~~~~~~~~~~~~~
<br>test.cpp:9:9: note: non-constexpr function 'non_constexpr_func' cannot =
be used in a constant expression
<br>&nbsp; &nbsp; &nbsp; &nbsp; non_constexpr_func(x);
<br>&nbsp; &nbsp; &nbsp; &nbsp; ^
<br>test.cpp:16:23: note: in call to 'constexpr_func(0)'
<br>&nbsp; &nbsp; constexpr int i =3D constexpr_func(0);
<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; ^
<br>test.cpp:2:1: note: declared here
<br>non_constexpr_func(int&amp;);
<br>^
<br>1 error generated.
<br>
<br>Howard
<br>
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2301_1598162847.1411927220937--

.

On 28 September 2014 21:00,  <inkwizytoryankes@gmail.com> wrote:
> Isn't this opposite that `constexpr` should do? Standard relay allow this or
> this is only bug in compiler?

No, it's not a bug. constexpr has a different meaning when used as a function
decorator and when used in a variable declaration. The former says
"can be used in
a constant expression, but might not result in a constant expression
with all argument
values", the latter says "shall be a constant expression". See how
Howard modifies
the code in his main.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_388_49102671.1411991931939
Content-Type: text/plain; charset=UTF-8


On Sunday, 28 September 2014 00:18:36 UTC+1, Myriachan wrote:
>
> I was going to mention throw, but then saw Jim's message with the same
> thing =).  Why don't we just modify the Standard as follows?:
>
> 1. throw would now be legal in a constexpr function ordinary statement
> (not enums and such) but not other constant-expressions.  This is a
> required change if we want to allow this, because there is no conditional
> expression:
>
> constexpr void abort_compile()
> {
>     throw "something bad happened";
> }
>
> 2. If evaluated at compile time, throw causes the top-level constexpr to
> become ill-formed, and a diagnostic is produced.  Since try is not allowed,
> exceptions will propagate all the way up until the top-level constexpr
> function.
>
> 3. The compiler diagnostic would be required to have the name of the type
> thrown, unless it was (possibly const-qualified) char *, wchar_t *,
> char16_t *, char32_t *, char (&)[X], wchar_t (&)[X], char16_t (&)[X] or
> char32_t (&)[X].  In those cases, it the diagnostic would include the
> printable contents of the string, with unspecified behavior for
> nonprintable characters and characters not representable in the character
> set used by the implementation's diagnostic messages.
>
> Melissa
>
> What about std::basic_string<char/wchar_t/char16_t/char32_t> and their
cv-qualified equivalents?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_388_49102671.1411991931939
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><BR>On Sunday, 28 September 2014 00:18:36 UTC+1, Myriachan=
 wrote:=20
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>I was going to mention throw, but =
then saw Jim's message with the same thing =3D). &nbsp;Why don't we just mo=
dify the Standard as follows?:=20
<P>1. throw would now be legal in a constexpr function ordinary statement (=
not enums and such) but not other constant-expressions. &nbsp;This is a req=
uired change if we want to allow this, because there is no conditional expr=
ession:=20
<P>constexpr void abort_compile()<BR>{<BR>&nbsp; &nbsp; throw "something ba=
d happened";<BR>}=20
<P>2. If evaluated at compile time, throw causes the top-level constexpr to=
 become ill-formed, and a diagnostic is produced. &nbsp;Since try is not al=
lowed, exceptions will propagate all the way up until the top-level constex=
pr function.=20
<P>3. The compiler diagnostic would be required to have the name of the typ=
e thrown, unless it was (possibly const-qualified) char *, wchar_t *, char1=
6_t *, char32_t *, char (&amp;)[X], wchar_t (&amp;)[X], char16_t (&amp;)[X]=
 or char32_t (&amp;)[X]. &nbsp;In those cases, it the diagnostic would incl=
ude the printable contents of the string, with unspecified behavior for non=
printable characters and characters not representable in the character set =
used by the implementation's diagnostic messages.=20
<P>Melissa</P>
<P></P></BLOCKQUOTE>
<DIV>What about std::basic_string&lt;char/wchar_t/char16_t/char32_t&gt; and=
 their cv-qualified equivalents?</DIV></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_388_49102671.1411991931939--

.

------=_Part_4194_1272642088.1412051780999
Content-Type: text/plain; charset=UTF-8

On Monday, September 29, 2014 4:58:51 AM UTC-7, Douglas Boffey wrote:
>
>
> On Sunday, 28 September 2014 00:18:36 UTC+1, Myriachan wrote:
>>
>> I was going to mention throw, but then saw Jim's message with the same
>> thing =).  Why don't we just modify the Standard as follows?:
>
>
>> 3. The compiler diagnostic would be required to have the name of the type
>> thrown, unless it was (possibly const-qualified) char *, wchar_t *,
>> char16_t *, char32_t *, char (&)[X], wchar_t (&)[X], char16_t (&)[X] or
>> char32_t (&)[X].  In those cases, it the diagnostic would include the
>> printable contents of the string, with unspecified behavior for
>> nonprintable characters and characters not representable in the character
>> set used by the implementation's diagnostic messages.
>>
>> What about std::basic_string<char/wchar_t/char16_t/char32_t> and their
> cv-qualified equivalents?
>

More like c-qualified equivalents, since volatile isn't allowed in
constexpr in most ways, I think...?

Are basic_string and friends allowed in constexpr?  I don't think that they
are now.

Anyway, yes, that sounds fine.  Modify #3 to also allow literal classes
constructed by usual constexpr rules that have a (possibly const-qualified)
(possibly non-static) member function c_str() or an operator X() for type X
that returns one of those eight aggregate character types.

Melissa

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4194_1272642088.1412051780999
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, September 29, 2014 4:58:51 AM UTC-7, Douglas Bo=
ffey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><b=
r>On Sunday, 28 September 2014 00:18:36 UTC+1, Myriachan wrote:=20
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">I was going to mention throw, but the=
n saw Jim's message with the same thing =3D). &nbsp;Why don't we just modif=
y the Standard as follows?:</blockquote></div></blockquote><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote style=3D"BORDER-L=
EFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class=3D"gmai=
l_quote"><br><p>3. The compiler diagnostic would be required to have the na=
me of the type thrown, unless it was (possibly const-qualified) char *, wch=
ar_t *, char16_t *, char32_t *, char (&amp;)[X], wchar_t (&amp;)[X], char16=
_t (&amp;)[X] or char32_t (&amp;)[X]. &nbsp;In those cases, it the diagnost=
ic would include the printable contents of the string, with unspecified beh=
avior for nonprintable characters and characters not representable in the c=
haracter set used by the implementation's diagnostic messages.=20
</p>
<p></p><p></p><p></p><p></p><p></p></blockquote>
<div>What about std::basic_string&lt;char/wchar_<wbr>t/char16_t/char32_t&gt=
; and their cv-qualified equivalents?</div></div></blockquote><div><br>More=
 like c-qualified equivalents, since volatile isn't allowed in constexpr in=
 most ways, I think...?<br><br>Are basic_string and friends allowed in cons=
texpr?&nbsp; I don't think that they are now.<br><br>Anyway, yes, that soun=
ds fine.&nbsp; Modify #3 to also allow literal classes constructed by usual=
 constexpr rules that have a (possibly const-qualified) (possibly non-stati=
c) member function c_str() or an operator X() for type X that returns one o=
f those eight aggregate character types.<br><br>Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4194_1272642088.1412051780999--

.

------=_Part_173_1081627612.1412762177810
Content-Type: text/plain; charset=UTF-8

Hi

Could someone tell me if makes sense to have a [[check_constexpr]]
attribute attachable to calls and functions that would result in a warning
if a specific call or any call to a checked function did not get computed
at compile time.

Thanks


On Sunday, September 28, 2014 5:42:19 AM UTC+13, Vittorio Romeo wrote:

> Problem:
> Using assertions in a `constexpr` function is currently not possible in
> C++14.
> As `constexpr` is used more and more, it has become a necessity (at least
> for me) to have a tool that allows me to perform debug checks on
> `constexpr` functions.
>
> Currently, there are no elegant or obvious ways to replicate the behavior
> of assertions in `constexpr` functions.
>
> http://stackoverflow.com/questions/26072709/alternative-to-asserts-for-constexpr-functions
>
> http://stackoverflow.com/questions/18648069/g-doesnt-compile-constexpr-function-with-assert-in-it/
>
>
>
> Proposal:
> I propose a new standard function/macro/whatever that allows the developer
> to assert certain predicates in `constexpr` functions.
>
> constexpr int getClamped(int mValue, int mMin, int mMax) noexcept
> {
>     // constexpr_assert(<predicate>, <optional message>);
>     constexpr_assert(mMin < mMax, "mMin must be smaller than mMax");
>
>     return mValue < mMin ? mMin : ((mValue > mMax) ? mMax : mValue);
> }
>
> int main()
> {
>     // "Obvious" compile-time evaluation
>     std::array<int, getClamped(5, 3, 4)> array;
>
>     // "Obvious" run-time evaluation
>     int x; std::cin >> x;
>     std::cout << getClamped(5, x, 10);
>
>     return 0;
> }
>
> `constexpr_assert(...)` would work very similarly to `assert(...)`. The
> user can specify an optional message as well.
>
> Now, there are two cases:
>
>    - *"Obvious" compile-time evaluation: *we are sure the `constexpr`
>    function is being evaluated at compile-time.
>       - *Ideal solution:* the compiler can verify the assertion predicate
>       at compile time and emit a compiler error in case the predicate is false.
>       - *Good-enough solution: *the compiler completely skips the
>       assertion check, allowing the code to compile properly and run. The
>       assertion will still work in "obvious" run-time evaluation scenarios.
>    - *"Obvious" run-time evaluation: *we are sure the `constexpr`
>    function is being evaluated at run-time.
>       - The assertion is practically treated as a normal `assert(...)`,
>       with the addition of an optional message that will displayed in case it
>       fires.
>
>
>
> Finishing thoughts:
> If this gets implemented, I think the standard should not require (but
> definitely encourage) compilers to be able to evaluate and check
> `constexpr_assert` assertions in "obvious" compile-time scenarios.
> The most important requirement would be allowing `constexpr` functions
> with `constexpr_assert` in them to always compile, independently on the
> fact that they're being evaluated at compile-time or run-time.
> In run-time scenarios, it's very simple to basically treat the
> `constexpr_assert` call as a normal assertion.
>
> What do you think?
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_173_1081627612.1412762177810
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi</div><div><br></div><div>Could someone tell me if&=
nbsp;makes sense to&nbsp;have a [[check_constexpr]] attribute attachable to=
 calls and functions that would result&nbsp;in a warning if&nbsp;a specific=
 call or any call to a checked function&nbsp;did not get&nbsp;computed at c=
ompile time.</div><div><br></div><div>Thanks</div><div><br></div><div><br><=
/div><div>On Sunday, September 28, 2014 5:42:19 AM UTC+13, Vittorio Romeo w=
rote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><font size=3D=
"4">Problem:</font></div>Using assertions in a `constexpr` function is curr=
ently not possible in C++14.&nbsp;<div>As `constexpr` is used more and more=
, it has become a necessity (at least for me) to have a tool that allows me=
 to perform debug checks on `constexpr` functions.</div><div><br></div><div=
>Currently, there are no elegant or obvious ways to replicate the behavior =
of assertions in `constexpr` functions.</div><div><a onmousedown=3D"this.hr=
ef=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquesti=
ons%2F26072709%2Falternative-to-asserts-for-constexpr-functions\46sa\75D\46=
sntz\0751\46usg\75AFQjCNENSjP9di5Hy7JsehqwP6N-WJZu1w';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.c=
om%2Fquestions%2F26072709%2Falternative-to-asserts-for-constexpr-functions\=
46sa\75D\46sntz\0751\46usg\75AFQjCNENSjP9di5Hy7JsehqwP6N-WJZu1w';return tru=
e;" href=3D"http://stackoverflow.com/questions/26072709/alternative-to-asse=
rts-for-constexpr-functions" target=3D"_blank">http://stackoverflow.com/<wb=
r>questions/26072709/<wbr>alternative-to-asserts-for-<wbr>constexpr-functio=
ns</a><br></div><div><a onmousedown=3D"this.href=3D'http://www.google.com/u=
rl?q\75http%3A%2F%2Fstackoverflow.com%2Fquestions%2F18648069%2Fg-doesnt-com=
pile-constexpr-function-with-assert-in-it%2F\46sa\75D\46sntz\0751\46usg\75A=
FQjCNFTbh8wkp4TSMnriCcgwAXmU1By_g';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquestions%2F18=
648069%2Fg-doesnt-compile-constexpr-function-with-assert-in-it%2F\46sa\75D\=
46sntz\0751\46usg\75AFQjCNFTbh8wkp4TSMnriCcgwAXmU1By_g';return true;" href=
=3D"http://stackoverflow.com/questions/18648069/g-doesnt-compile-constexpr-=
function-with-assert-in-it/" target=3D"_blank">http://stackoverflow.com/<wb=
r>questions/18648069/g-doesnt-<wbr>compile-constexpr-function-<wbr>with-ass=
ert-in-it/</a><br></div><div><br></div><div><br></div><div><br></div><div><=
font size=3D"4">Proposal:</font></div><div><font size=3D"2">I propose a new=
 standard function/macro/whatever that allows the developer to assert certa=
in predicates in `constexpr` functions.</font></div><div><font size=3D"2"><=
br></font></div><div><font size=3D"2"><div style=3D"border: 1px solid rgb(1=
87, 187, 187); border-image: none; -ms-word-wrap: break-word; background-co=
lor: rgb(250, 250, 250);"><code><div><span style=3D"color: rgb(0, 0, 136);"=
>constexpr</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=
=3D"color: rgb(0, 0, 136);">int</span><span style=3D"color: rgb(0, 0, 0);">=
 getClamped</span><span style=3D"color: rgb(102, 102, 0);">(</span><span st=
yle=3D"color: rgb(0, 0, 136);">int</span><span style=3D"color: rgb(0, 0, 0)=
;"> mValue</span><span style=3D"color: rgb(102, 102, 0);">,</span><span sty=
le=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">=
int</span><span style=3D"color: rgb(0, 0, 0);"> mMin</span><span style=3D"c=
olor: rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, 0, 0);"> </sp=
an><span style=3D"color: rgb(0, 0, 136);">int</span><span style=3D"color: r=
gb(0, 0, 0);"> mMax</span><span style=3D"color: rgb(102, 102, 0);">)</span>=
<span style=3D"color: rgb(0, 0, 0);"> noexcept<br></span><span style=3D"col=
or: rgb(102, 102, 0);">{</span><span style=3D"color: rgb(0, 0, 0);"><br>&nb=
sp; &nbsp; </span><span style=3D"color: rgb(136, 0, 0);">// constexpr_asser=
t(&lt;predicate&gt;, &lt;optional message&gt;);</span><span style=3D"color:=
 rgb(0, 0, 0);"><br>&nbsp; &nbsp; constexpr_assert</span><span style=3D"col=
or: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 0);">mMin </=
span><span style=3D"color: rgb(102, 102, 0);">&lt;</span><span style=3D"col=
or: rgb(0, 0, 0);"> mMax</span><span style=3D"color: rgb(102, 102, 0);">,</=
span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb=
(0, 136, 0);">"mMin must be smaller than mMax"</span><span style=3D"color: =
rgb(102, 102, 0);">);</span><span style=3D"color: rgb(0, 0, 0);"><br><br>&n=
bsp; &nbsp; </span><span style=3D"color: rgb(0, 0, 136);">return</span><spa=
n style=3D"color: rgb(0, 0, 0);"> mValue </span><span style=3D"color: rgb(1=
02, 102, 0);">&lt;</span><span style=3D"color: rgb(0, 0, 0);"> mMin </span>=
<span style=3D"color: rgb(102, 102, 0);">?</span><span style=3D"color: rgb(=
0, 0, 0);"> </span><font color=3D"#666600"><span style=3D"color: rgb(0, 0, =
0);">mMin </span><span style=3D"color: rgb(102, 102, 0);">:</span><span sty=
le=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, 0);=
">((</span><span style=3D"color: rgb(0, 0, 0);">mValue </span><span style=
=3D"color: rgb(102, 102, 0);">&gt;</span><span style=3D"color: rgb(0, 0, 0)=
;"> mMax</span><span style=3D"color: rgb(102, 102, 0);">)</span><span style=
=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, 0);">=
?</span><span style=3D"color: rgb(0, 0, 0);"> mMax </span><span style=3D"co=
lor: rgb(102, 102, 0);">:</span><span style=3D"color: rgb(0, 0, 0);"> mValu=
e</span><span style=3D"color: rgb(102, 102, 0);">);</span></font><span styl=
e=3D"color: rgb(0, 0, 0);"><br></span><span style=3D"color: rgb(102, 102, 0=
);">}</span><span style=3D"color: rgb(0, 0, 0);"><br><br></span><span style=
=3D"color: rgb(0, 0, 136);">int</span><span style=3D"color: rgb(0, 0, 0);">=
 main</span><span style=3D"color: rgb(102, 102, 0);">()</span><span style=
=3D"color: rgb(0, 0, 0);"><br></span><span style=3D"color: rgb(102, 102, 0)=
;">{</span><span style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; </span><s=
pan style=3D"color: rgb(136, 0, 0);">// "Obvious" compile-time evaluation</=
span><span style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; std</span><span=
 style=3D"color: rgb(102, 102, 0);">::</span><span style=3D"color: rgb(0, 0=
, 0);">array</span><span style=3D"color: rgb(102, 102, 0);">&lt;</span><spa=
n style=3D"color: rgb(0, 0, 136);">int</span><span style=3D"color: rgb(102,=
 102, 0);">,</span><span style=3D"color: rgb(0, 0, 0);"> getClamped</span><=
span style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0=
, 102, 102);">5</span><span style=3D"color: rgb(102, 102, 0);">,</span><spa=
n style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 102, =
102);">3</span><span style=3D"color: rgb(102, 102, 0);">,</span><span style=
=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 102, 102);">=
4</span><span style=3D"color: rgb(102, 102, 0);">)&gt;</span><span style=3D=
"color: rgb(0, 0, 0);"> array</span><span style=3D"color: rgb(102, 102, 0);=
">;</span><span style=3D"color: rgb(0, 0, 0);"><br><br>&nbsp; &nbsp; </span=
><span style=3D"color: rgb(136, 0, 0);">// "Obvious" run-time evaluation</s=
pan><span style=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; </span><span sty=
le=3D"color: rgb(0, 0, 136);">int</span><span style=3D"color: rgb(0, 0, 0);=
"> x</span><span style=3D"color: rgb(102, 102, 0);">;</span><font color=3D"=
#000000"><span style=3D"color: rgb(0, 0, 0);"> std</span><span style=3D"col=
or: rgb(102, 102, 0);">::</span><span style=3D"color: rgb(0, 0, 0);">cin </=
span><span style=3D"color: rgb(102, 102, 0);">&gt;&gt;</span><span style=3D=
"color: rgb(0, 0, 0);"> x</span><span style=3D"color: rgb(102, 102, 0);">;<=
/span><span style=3D"color: rgb(0, 0, 0);"> <br>&nbsp; &nbsp; std</span><sp=
an style=3D"color: rgb(102, 102, 0);">::</span><span style=3D"color: rgb(0,=
 0, 0);">cout </span><span style=3D"color: rgb(102, 102, 0);">&lt;&lt;</spa=
n><span style=3D"color: rgb(0, 0, 0);"> getClamped</span><span style=3D"col=
or: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 102, 102);">5</=
span><span style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"color:=
 rgb(0, 0, 0);"> x</span><span style=3D"color: rgb(102, 102, 0);">,</span><=
span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 10=
2, 102);">10</span><span style=3D"color: rgb(102, 102, 0);">);</span><span =
style=3D"color: rgb(0, 0, 0);"><br><br>&nbsp; &nbsp; </span><span style=3D"=
color: rgb(0, 0, 136);">return</span><span style=3D"color: rgb(0, 0, 0);"> =
</span><span style=3D"color: rgb(0, 102, 102);">0</span><span style=3D"colo=
r: rgb(102, 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"><br></sp=
an><span style=3D"color: rgb(102, 102, 0);">}</span></font></div></code></d=
iv><br>`constexpr_assert(...)` would work very similarly to `assert(...)`. =
The user can specify an optional message as well.</font></div><div><font si=
ze=3D"2"><br></font></div><div><font size=3D"2">Now, there are two cases:</=
font></div><div><ul><li><font size=3D"2"><span style=3D"line-height: normal=
;"><b>"Obvious" compile-time evaluation: </b>we are sure the `constexpr` fu=
nction is being evaluated at compile-time.</span></font></li><ul><li><font =
size=3D"2"><span style=3D"line-height: normal;"><b>Ideal solution:</b> the =
compiler can verify the assertion predicate at compile time and emit a comp=
iler error in case the predicate is false.</span></font></li><li><font size=
=3D"2"><span style=3D"line-height: normal;"><b>Good-enough solution: </b>th=
e compiler completely skips the assertion check, allowing the code to compi=
le properly and run. The assertion will still work in "obvious" run-time ev=
aluation scenarios.</span></font></li></ul><li><font size=3D"2"><span style=
=3D"line-height: normal;"><b>"Obvious" run-time evaluation: </b>we are sure=
 the `constexpr` function is being evaluated at run-time.</span></font></li=
><ul><li><font size=3D"2"><span style=3D"line-height: normal;">The assertio=
n is practically treated as a normal `assert(...)`, with the addition of an=
 optional message that will displayed in case it fires.</span></font></li><=
/ul></ul><div><br></div></div><div><br></div><div><font size=3D"4">Finishin=
g thoughts:</font></div><div><font size=3D"2">If this gets implemented, I t=
hink the standard should not require (but definitely encourage) compilers t=
o be able to evaluate and check `constexpr_assert` assertions in "obvious" =
compile-time scenarios.&nbsp;</font></div><div><font size=3D"2">The most im=
portant requirement would be allowing `constexpr` functions with `constexpr=
_assert` in them to always compile, independently on the fact that they're =
being evaluated at compile-time or run-time.</font></div><div>In run-time s=
cenarios, it's very simple to basically treat the `constexpr_assert` call a=
s a normal assertion.<br><br>What do you think?</div><div><font size=3D"4">=
<br></font></div></div></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_173_1081627612.1412762177810--

.

On Wednesday, 8 October 2014 10:56:17 UTC+1, gmis...@gmail.com  wrote:
> Could someone tell me if=C2=A0makes sense to=C2=A0have a [[check_constexp=
r]] attribute attachable to calls and functions that would result=C2=A0in a=
 warning if=C2=A0a specific call or any call to a checked function=C2=A0did=
 not get=C2=A0computed at compile time.

What's wrong with using integral_constant to force compile time evaluation?

--=20

---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_141_211253653.1412815952216
Content-Type: text/plain; charset=UTF-8



On Thursday, October 9, 2014 11:46:12 AM UTC+13, Edward Catmur wrote:
>
> On Wednesday, 8 October 2014 10:56:17 UTC+1, gmis...@gmail.com  wrote:
> > Could someone tell me if makes sense to have a [[check_constexpr]]
> attribute attachable to calls and functions that would result in a warning
> if a specific call or any call to a checked function did not get computed
> at compile time.
>
> What's wrong with using integral_constant to force compile time evaluation?


I wasn't trying to solve the specific example function. I was trying to
solve all examples of the general problem.
Your answer sounds like it was just trying to solve the specific example.
Am I correct?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_141_211253653.1412815952216
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 9, 2014 11:46:12 AM UTC+13, E=
dward Catmur wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">On Wednesday, 8 October 201=
4 10:56:17 UTC+1, <a>gmis...@gmail.com</a> &nbsp;wrote:
<br>&gt; Could someone tell me if&nbsp;makes sense to&nbsp;have a [[check_c=
onstexpr]] attribute attachable to calls and functions that would result&nb=
sp;in a warning if&nbsp;a specific call or any call to a checked function&n=
bsp;did not get&nbsp;computed at compile time.
<br>
<br>What's wrong with using integral_constant to force compile time evaluat=
ion?</blockquote><div><br></div><div>I wasn't trying to solve the specific =
example function. I was trying&nbsp;to solve all examples of the general pr=
oblem.</div><div>Your answer sounds like it was just trying to solve the sp=
ecific example. Am I correct?</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_141_211253653.1412815952216--

.

--001a11350eac5646a105051f977b
Content-Type: text/plain; charset=UTF-8

On 9 Oct 2014 01:52, <gmisocpp@gmail.com> wrote:
> On Thursday, October 9, 2014 11:46:12 AM UTC+13, Edward Catmur wrote:
>> On Wednesday, 8 October 2014 10:56:17 UTC+1, gmis...@gmail.com  wrote:
>> > Could someone tell me if makes sense to have a [[check_constexpr]]
attribute attachable to calls and functions that would result in a warning
if a specific call or any call to a checked function did not get computed
at compile time.
>>
>> What's wrong with using integral_constant to force compile time
evaluation?
>
>
> I wasn't trying to solve the specific example function. I was trying to
solve all examples of the general problem.
> Your answer sounds like it was just trying to solve the specific example.
Am I correct?

You didn't provide a specific example, so I don't know what the general
problem is. Could you provide an example?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11350eac5646a105051f977b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">On 9 Oct 2014 01:52, &lt;<a href=3D"mailto:gmisocpp@gmail.co=
m">gmisocpp@gmail.com</a>&gt; wrote:<br>
&gt; On Thursday, October 9, 2014 11:46:12 AM UTC+13, Edward Catmur wrote:<=
br>
&gt;&gt; On Wednesday, 8 October 2014 10:56:17 UTC+1, <a href=3D"mailto:gmi=
s...@gmail.com">gmis...@gmail.com</a> =C2=A0wrote: <br>
&gt;&gt; &gt; Could someone tell me if=C2=A0makes sense to=C2=A0have a [[ch=
eck_constexpr]] attribute attachable to calls and functions that would resu=
lt=C2=A0in a warning if=C2=A0a specific call or any call to a checked funct=
ion=C2=A0did not get=C2=A0computed at compile time. <br>
&gt;&gt;<br>
&gt;&gt; What&#39;s wrong with using integral_constant to force compile tim=
e evaluation?<br>
&gt;<br>
&gt;<br>
&gt; I wasn&#39;t trying to solve the specific example function. I was tryi=
ng=C2=A0to solve all examples of the general problem.<br>
&gt; Your answer sounds like it was just trying to solve the specific examp=
le. Am I correct?</p>
<p dir=3D"ltr">You didn&#39;t provide a specific example, so I don&#39;t kn=
ow what the general problem is. Could you provide an example? </p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11350eac5646a105051f977b--

.

------=_Part_250_520084949.1413024476134
Content-Type: text/plain; charset=UTF-8



On Saturday, October 11, 2014 7:15:25 PM UTC+13, Edward Catmur wrote:
>
> On 9 Oct 2014 01:52, <gmis...@gmail.com <javascript:>> wrote:
> > On Thursday, October 9, 2014 11:46:12 AM UTC+13, Edward Catmur wrote:
> >> On Wednesday, 8 October 2014 10:56:17 UTC+1, gmis...@gmail.com  wrote:
> >> > Could someone tell me if makes sense to have a [[check_constexpr]]
> attribute attachable to calls and functions that would result in a warning
> if a specific call or any call to a checked function did not get computed
> at compile time.
> >>
> >> What's wrong with using integral_constant to force compile time
> evaluation?
> >
> >
> > I wasn't trying to solve the specific example function. I was trying to
> solve all examples of the general problem.
> > Your answer sounds like it was just trying to solve the specific
> example. Am I correct?
>
> You didn't provide a specific example, so I don't know what the general
> problem is. Could you provide an example?
>

Take the example from earlier in this thread:
constexpr int getClamped(int mValue, int mMin, int mMax) noexcept
{
    return mValue < mMin ? mMin : ((mValue > mMax) ? mMax : mValue);
}

If you want to ensure any call to this function will be compile time
evaluated and if not yield a warning. How do you do it?



--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_250_520084949.1413024476134
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, October 11, 2014 7:15:25 PM UTC+13, E=
dward Catmur wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><p dir=3D"ltr">On 9 Oct 201=
4 01:52, &lt;<a onmousedown=3D"this.href=3D'javascript:';return true;" oncl=
ick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"97f4fEEjd7IJ">gmis...@gmail.com</a>&gt=
; wrote:<br>
&gt; On Thursday, October 9, 2014 11:46:12 AM UTC+13, Edward Catmur wrote:<=
br>
&gt;&gt; On Wednesday, 8 October 2014 10:56:17 UTC+1, <a>gmis...@gmail.com<=
/a> &nbsp;wrote: <br>
&gt;&gt; &gt; Could someone tell me if&nbsp;makes sense to&nbsp;have a [[ch=
eck_constexpr]] attribute attachable to calls and functions that would resu=
lt&nbsp;in a warning if&nbsp;a specific call or any call to a checked funct=
ion&nbsp;did not get&nbsp;computed at compile time. <br>
&gt;&gt;<br>
&gt;&gt; What's wrong with using integral_constant to force compile time ev=
aluation?<br>
&gt;<br>
&gt;<br>
&gt; I wasn't trying to solve the specific example function. I was trying&n=
bsp;to solve all examples of the general problem.<br>
&gt; Your answer sounds like it was just trying to solve the specific examp=
le. Am I correct?</p>
<p dir=3D"ltr">You didn't provide a specific example, so I don't know what =
the general problem is. Could you provide an example? </p></blockquote><div=
><br></div><div>Take the example from earlier in this thread: </div><div>co=
nstexpr int getClamped(int mValue, int mMin, int mMax) noexcept <br>{ <br>&=
nbsp;&nbsp;&nbsp; return mValue &lt; mMin ? mMin : ((mValue &gt; mMax) ? mM=
ax : mValue); <br>}</div><div><br></div><div>If you want to ensure any call=
 to this function will be compile time evaluated and if not yield a warning=
.. How do you do it?</div><div><br>&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_250_520084949.1413024476134--

.

--001a11c11d123a605605052523c0
Content-Type: text/plain; charset=UTF-8

On 11 Oct 2014 11:47, <gmisocpp@gmail.com> wrote:
> Take the example from earlier in this thread:
> constexpr int getClamped(int mValue, int mMin, int mMax) noexcept
> {
>     return mValue < mMin ? mMin : ((mValue > mMax) ? mMax : mValue);
> }
>
> If you want to ensure any call to this function will be compile time
evaluated and if not yield a warning. How do you do it?

template<int mValue, int mMin, int mMax>
using GetClamped = std::integral_constant<int,
    getClamped(mValue, mMin, mMax)>;

Although I'm not sure why you'd want to prevent the function being
evaluated at run time.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c11d123a605605052523c0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">On 11 Oct 2014 11:47, &lt;<a href=3D"mailto:gmisocpp@gmail.c=
om">gmisocpp@gmail.com</a>&gt; wrote:<br>
&gt; Take the example from earlier in this thread:<br>
&gt; constexpr int getClamped(int mValue, int mMin, int mMax) noexcept <br>
&gt; { <br>
&gt; =C2=A0=C2=A0=C2=A0 return mValue &lt; mMin ? mMin : ((mValue &gt; mMax=
) ? mMax : mValue); <br>
&gt; }<br>
&gt;<br>
&gt; If you want to ensure any call to this function will be compile time e=
valuated and if not yield a warning. How do you do it?</p>
<p dir=3D"ltr">template&lt;int mValue, int mMin, int mMax&gt;<br>
using GetClamped =3D std::integral_constant&lt;int,<br>
=C2=A0=C2=A0=C2=A0 getClamped(mValue, mMin, mMax)&gt;;</p>
<p dir=3D"ltr">Although I&#39;m not sure why you&#39;d want to prevent the =
function being evaluated at run time. </p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c11d123a605605052523c0--

.

------=_Part_39_1902348000.1413042593856
Content-Type: text/plain; charset=UTF-8



On Sunday, October 12, 2014 1:52:27 AM UTC+13, Edward Catmur wrote:
>
> On 11 Oct 2014 11:47, <gmis...@gmail.com <javascript:>> wrote:
> > Take the example from earlier in this thread:
> > constexpr int getClamped(int mValue, int mMin, int mMax) noexcept
> > {
> >     return mValue < mMin ? mMin : ((mValue > mMax) ? mMax : mValue);
> > }
> >
> > If you want to ensure any call to this function will be compile time
> evaluated and if not yield a warning. How do you do it?
>
> template<int mValue, int mMin, int mMax>
> using GetClamped = std::integral_constant<int,
>     getClamped(mValue, mMin, mMax)>;
>
> Although I'm not sure why you'd want to prevent the function being
> evaluated at run time.
>

The goal was not to prevent it being evaluated at runtime.

The goal was to be able to *know* if it will be evaluated at runtime or
not, so a warning can be generated or not.

And the question was how useful did people see this feature as being.

I had been thinking an attribute would make this easier than what you wrote
and I was looking at use cases like this:

// variant 1
x = getClampled [[constexpr_check]] (v,mi,mx); // Warn if this call to f is
not compile time evaluated.

// variant 2
x = getClamped(v,mi,mx); // getClampled definition has [[constexpr_check]]
so all calls to getClamed are implicitly checked to be compile time
evaluated and warned about if not.

Perhaps your idea could be taken further with variadic templates and a
boost static warning type something to yield things of more utility, e.g.:
checked_constexpr_call( getClampled, v, mi, mx );

Maybe both routes have value. But I'm thinking the more commonly useful the
feature is, the better it would be to be if were as easy as possible to
do/define.
So I'm trying to get a handle on what people feel about that question.

Maybe the utility can be assembled from the parts of being able to query if
a function call will be compile time evaluated and then doing something
with that info like static_asserting or something.

But I'm asking people what value do they see in this type of thing and if
it has value how much so and how best to put it together based on that
value.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_39_1902348000.1413042593856
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, October 12, 2014 1:52:27 AM UTC+13, Edw=
ard Catmur wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><p dir=3D"ltr">On 11 Oct 2014=
 11:47, &lt;<a onmousedown=3D"this.href=3D'javascript:';return true;" oncli=
ck=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"FL2UaDVRTAAJ">gmis...@gmail.com</a>&gt=
; wrote:<br>
&gt; Take the example from earlier in this thread:<br>
&gt; constexpr int getClamped(int mValue, int mMin, int mMax) noexcept <br>
&gt; { <br>
&gt; &nbsp;&nbsp;&nbsp; return mValue &lt; mMin ? mMin : ((mValue &gt; mMax=
) ? mMax : mValue); <br>
&gt; }<br>
&gt;<br>
&gt; If you want to ensure any call to this function will be compile time e=
valuated and if not yield a warning. How do you do it?</p>
<p dir=3D"ltr">template&lt;int mValue, int mMin, int mMax&gt;<br>
using GetClamped =3D std::integral_constant&lt;int,<br>
&nbsp;&nbsp;&nbsp; getClamped(mValue, mMin, mMax)&gt;;</p>
<p dir=3D"ltr">Although I'm not sure why you'd want to prevent the function=
 being evaluated at run time. </p></blockquote><div><br></div><div>The goal=
 was not to prevent it being evaluated at runtime.</div><div><br></div><div=
>The goal was to be able to *know* if it will be evaluated at runtime&nbsp;=
or not, so&nbsp;a warning can&nbsp;be generated&nbsp;or not.</div><div><br>=
</div><div>And the question was&nbsp;how useful did people see this feature=
 as being.</div><div><br></div><div>I&nbsp;had been thinking&nbsp;an attrib=
ute would&nbsp;make this easier than what you wrote and I was looking at us=
e cases like this:</div><div><br></div><div><div>// variant 1</div><div>x =
=3D&nbsp;getClampled&nbsp;[[constexpr_check]] (v,mi,mx); // Warn if this ca=
ll to f is not compile time evaluated.</div><div><br></div><div>// variant =
2</div><div>x =3D getClamped(v,mi,mx); //&nbsp;getClampled definition has&n=
bsp;[[constexpr_check]]&nbsp; so all calls to getClamed&nbsp;are implicitly=
 checked to be compile time evaluated and warned about if not.</div><div><b=
r></div></div><div>Perhaps&nbsp;your idea&nbsp;could be&nbsp;taken further =
with&nbsp;variadic templates&nbsp;and a boost static warning&nbsp;type some=
thing&nbsp;to yield&nbsp;things of more utility, e.g.:</div><div>checked_co=
nstexpr_call( getClampled, v, mi, mx );</div><div><br></div><div>Maybe both=
 routes have value. But I'm thinking the&nbsp;more commonly useful the feat=
ure is,&nbsp;the better it would be to be if were as easy as possible to do=
/define.</div><div>So I'm trying to get a handle on what people feel about =
that question.</div><div><br></div><div>Maybe the utility&nbsp;can be&nbsp;=
assembled from the parts of being able to query if a function call&nbsp;wil=
l be&nbsp;compile time evaluated&nbsp;and then doing something with that in=
fo&nbsp;like static_asserting or something.</div><div><br></div><div><div>B=
ut I'm&nbsp;asking people what value do they see in this type of thing and =
if it has value how much so and&nbsp;how best to put it together based on t=
hat value.</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_39_1902348000.1413042593856--

.

--001a11c2b4cc0cf2a505053b552e
Content-Type: text/plain; charset=UTF-8

On Sat, Oct 11, 2014 at 4:49 PM, <gmisocpp@gmail.com> wrote:

> The goal was not to prevent it being evaluated at runtime.
>

> The goal was to be able to *know* if it will be evaluated at runtime or
> not, so a warning can be generated or not.
>

I'm still not clear why you'd want to do this. If you don't want people to
use your interface incorrectly, give them an interface that can only be
used correctly to begin with. Except for a very few cases ([[deprecated]]
being one), warnings are either treated as errors (-Werror) or ignored, so
provide very little value.


> Maybe the utility can be assembled from the parts of being able to query
> if a function call will be compile time evaluated and then doing something
> with that info like static_asserting or something.
>

Overloading on constexpr would allow this - you could deprecate or delete
the non-constexpr overload. I can't recall how far the latest constexpr
overloading proposal got, but this is probably worth mentioning as a
motivation next time it makes the rounds.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c2b4cc0cf2a505053b552e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sat, Oct 11, 2014 at 4:49 PM,  <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:gmisocpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a=
>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The goal was not to preve=
nt it being evaluated at runtime.<br></div></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><br></div><div>The goal was to be able =
to *know* if it will be evaluated at runtime=C2=A0or not, so=C2=A0a warning=
 can=C2=A0be generated=C2=A0or not.</div></div></blockquote><div><br></div>=
<div>I&#39;m still not clear why you&#39;d want to do this. If you don&#39;=
t want people to use your interface incorrectly, give them an interface tha=
t can only be used correctly to begin with. Except for a very few cases ([[=
deprecated]] being one), warnings are either treated as errors (-Werror) or=
 ignored, so provide very little value.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div>Maybe the utility=C2=A0can be=C2=A0=
assembled from the parts of being able to query if a function call=C2=A0wil=
l be=C2=A0compile time evaluated=C2=A0and then doing something with that in=
fo=C2=A0like static_asserting or something.</div></div></blockquote><div><b=
r></div><div>Overloading on constexpr would allow this - you could deprecat=
e or delete the non-constexpr overload. I can&#39;t recall how far the late=
st constexpr overloading proposal got, but this is probably worth mentionin=
g as a motivation next time it makes the rounds.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2b4cc0cf2a505053b552e--

.

------=_Part_2228_1882169332.1413143618429
Content-Type: text/plain; charset=UTF-8

On Sunday, October 12, 2014 8:21:13 AM UTC-7, Edward Catmur wrote:
>
> On Sat, Oct 11, 2014 at 4:49 PM, <gmis...@gmail.com <javascript:>> wrote:
>
>
>> Maybe the utility can be assembled from the parts of being able to query
>> if a function call will be compile time evaluated and then doing something
>> with that info like static_asserting or something.
>>
>
> Overloading on constexpr would allow this - you could deprecate or delete
> the non-constexpr overload. I can't recall how far the latest constexpr
> overloading proposal got, but this is probably worth mentioning as a
> motivation next time it makes the rounds.
>

Overloading on constexpr could be really awesome if done such that function
parameters may be used as template parameters within a constexpr-overloaded
function.  For example, it would allow the implementation of string to
char... parameter pack conversion.

Melissa

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_2228_1882169332.1413143618429
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, October 12, 2014 8:21:13 AM UTC-7, Edward Catmu=
r wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Sa=
t, Oct 11, 2014 at 4:49 PM,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"ju9pknM-GrcJ" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">gmis...@gmail.com</a>&gt;</span> wrote:<br><div><div class=3D"=
gmail_quote"><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div>Maybe the utility&nbsp;can be&nbsp;assembled from the parts of bein=
g able to query if a function call&nbsp;will be&nbsp;compile time evaluated=
&nbsp;and then doing something with that info&nbsp;like static_asserting or=
 something.</div></div></blockquote><div><br></div><div>Overloading on cons=
texpr would allow this - you could deprecate or delete the non-constexpr ov=
erload. I can't recall how far the latest constexpr overloading proposal go=
t, but this is probably worth mentioning as a motivation next time it makes=
 the rounds.</div></div></div></div></blockquote><div><br>Overloading on <s=
pan style=3D"font-family: courier new,monospace;">constexpr</span> could be=
 really awesome if done such that function parameters may be used as templa=
te parameters within a <span style=3D"font-family: courier new,monospace;">=
constexpr</span>-overloaded function.&nbsp; For example, it would allow the=
 implementation of string to <span style=3D"font-family: courier new,monosp=
ace;">char...</span> parameter pack conversion.<br><br>Melissa<br></div></d=
iv>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2228_1882169332.1413143618429--

.