Topic: About functional purity and attribute [[pure]]
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Fri, 11 Dec 2015 15:18:52 -0500
Raw View
After the digression in the thread on defining order of evaluation, I
read through P0078r0 for the first time.
My biggest problem with supporting only GCC's ((const)) is that it
excludes the majority of methods that could otherwise be annotated. (Use
of "methods" there rather than "functions" should suggest the major
class of what would be excluded.)
At some point, however, it occurred to me... do we already *have* this?
How close is existing constexpr support to "true" purity? (And more
interestingly, do any compilers perform purity-like optimizations based
on whether a function is constexpr?)
Of course, there are proposals trying to make impure things possible at
compile time, which would obviously cause constexpr to diverge from any
notion of purity...
--
Matthew
--
---
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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 11 Dec 2015 23:37:29 -0800
Raw View
On Friday 11 December 2015 15:18:52 Matthew Woehlke wrote:
> At some point, however, it occurred to me... do we already *have* this?
> How close is existing constexpr support to "true" purity? (And more
> interestingly, do any compilers perform purity-like optimizations based
> on whether a function is constexpr?)
All constexpr evaluation is pure. But all constexpr is also inline. Pure
functions don't need to be inline and that's the whole reason why it's an
attribute, not a keyword.
> Of course, there are proposals trying to make impure things possible at
> compile time, which would obviously cause constexpr to diverge from any
> notion of purity...
--
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: leni536@gmail.com
Date: Tue, 15 Dec 2015 04:37:00 -0800 (PST)
Raw View
------=_Part_2896_1270035347.1450183020533
Content-Type: multipart/alternative;
boundary="----=_Part_2897_1823035848.1450183020533"
------=_Part_2897_1823035848.1450183020533
Content-Type: text/plain; charset=UTF-8
>
> All constexpr evaluation is pure.
>
Are you sure? I found this gem, I wonder if it's actually not standard
compliant or constexpr functions aren't actually pure.
http://b.atch.se/posts/non-constant-constant-expressions/
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2897_1823035848.1450183020533
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">All constexpr=
evaluation is pure.<br></blockquote><div><br></div><div>Are you sure? I fo=
und this gem, I wonder if it's actually not standard compliant or const=
expr functions aren't actually pure.</div><div><br></div><div>http://b.=
atch.se/posts/non-constant-constant-expressions/=C2=A0</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" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_2897_1823035848.1450183020533--
------=_Part_2896_1270035347.1450183020533--
.
Author: "'Johannes Schaub' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 15 Dec 2015 14:03:10 +0100
Raw View
--001a11401efe63749e0526ef6988
Content-Type: text/plain; charset=UTF-8
That post reads as though the Standard is a rigorous set of rules that you
can apply and if strictly adhering to the rules, you can have that
technique like compile time modifiable structures.
But actually the Standard is more like a set of rules that often leave much
wiggle room for interpretation and where you have to consult a huge list of
active issues and fixed defects and mailings to infer the intended meaning
of the wiggling rules.
So you better adhere to the general statement of intents which in this case
are "constexpr means pureness."
Am 15.12.2015 13:37 schrieb <leni536@gmail.com>:
>>
>> All constexpr evaluation is pure.
>
>
> Are you sure? I found this gem, I wonder if it's actually not standard
compliant or constexpr functions aren't actually pure.
>
> http://b.atch.se/posts/non-constant-constant-expressions/
>
> --
>
> ---
> 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
https://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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11401efe63749e0526ef6988
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">That post reads as though the Standard is a rigorous set of =
rules that you can apply and if strictly adhering to the rules, you can hav=
e that technique like compile time modifiable structures. </p>
<p dir=3D"ltr">But actually the Standard is more like a set of rules that o=
ften leave much wiggle room for interpretation and where you have to consul=
t a huge list of active issues and fixed defects and mailings to infer the =
intended meaning of the wiggling rules. </p>
<p dir=3D"ltr">So you better adhere to the general statement of intents whi=
ch in this case are "constexpr means pureness."<br><br></p>
<p dir=3D"ltr">Am 15.12.2015 13:37 schrieb <<a href=3D"mailto:leni536@gm=
ail.com">leni536@gmail.com</a>>:<br>
>><br>
>> All constexpr evaluation is pure.<br>
><br>
><br>
> Are you sure? I found this gem, I wonder if it's actually not stan=
dard compliant or constexpr functions aren't actually pure.<br>
><br>
> <a href=3D"http://b.atch.se/posts/non-constant-constant-expressions/">=
http://b.atch.se/posts/non-constant-constant-expressions/</a>=C2=A0<br>
><br>
> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/=
group/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-prop=
osals/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a11401efe63749e0526ef6988--
.
Author: "S.B." <i.and.my.little.friends@gmail.com>
Date: Tue, 15 Dec 2015 05:46:34 -0800 (PST)
Raw View
------=_Part_79_1776654381.1450187194390
Content-Type: multipart/alternative;
boundary="----=_Part_80_796386423.1450187194395"
------=_Part_80_796386423.1450187194395
Content-Type: text/plain; charset=UTF-8
On Tuesday, December 15, 2015 at 8:37:00 PM UTC+8, len...@gmail.com wrote:
>
> All constexpr evaluation is pure.
>>
>
> Are you sure? I found this gem, I wonder if it's actually not standard
> compliant or constexpr functions aren't actually pure.
>
> http://b.atch.se/posts/non-constant-constant-expressions/
>
cwg2118 <http://wg21.link/cwg2118>
"CWG agreed that such techniques should be ill-formed, although the
mechanism for prohibiting them is as yet undetermined."
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_80_796386423.1450187194395
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Tuesday, December 15, 2015 at 8:37:00 PM UTC+8, len...@gmail.com=
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"><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex">All constexpr evaluation is pure.<br></bl=
ockquote><div><br></div><div>Are you sure? I found this gem, I wonder if it=
's actually not standard compliant or constexpr functions aren't ac=
tually pure.</div><div><br></div><div><a href=3D"http://b.atch.se/posts/non=
-constant-constant-expressions/" target=3D"_blank" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fb.atch.=
se%2Fposts%2Fnon-constant-constant-expressions%2F\46sa\75D\46sntz\0751\46us=
g\75AFQjCNHebJU3MB8efOdfkSelW9QJCNhsrw';return true;" onclick=3D"this.h=
ref=3D'http://www.google.com/url?q\75http%3A%2F%2Fb.atch.se%2Fposts%2Fn=
on-constant-constant-expressions%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNHebJ=
U3MB8efOdfkSelW9QJCNhsrw';return true;">http://b.atch.se/posts/non-<wbr=
>constant-constant-expressions/</a><wbr>=C2=A0</div></div></blockquote><div=
><br><a href=3D"http://wg21.link/cwg2118">cwg2118</a><br>"CWG agreed t=
hat such techniques should be ill-formed,
although the mechanism for prohibiting them is as yet
undetermined."=C2=A0</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_80_796386423.1450187194395--
------=_Part_79_1776654381.1450187194390--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 15 Dec 2015 10:19:13 -0800
Raw View
--001a11439cd0a569a80526f3d311
Content-Type: text/plain; charset=UTF-8
On Tue, Dec 15, 2015 at 4:37 AM, <leni536@gmail.com> wrote:
> All constexpr evaluation is pure.
>>
>
> Are you sure? I found this gem, I wonder if it's actually not standard
> compliant or constexpr functions aren't actually pure.
>
> http://b.atch.se/posts/non-constant-constant-expressions/
>
Note that the techniques that accomplish this do one of two things:
1) Call a different function each time (despite using the same function
name and arguments), or
2) Call the function with different arguments each time (through default
arguments that are different on subsequent calls)
But you need to be more precise with your words. As Thiago said, "all
constexpr evaluation is pure". But that does *not* imply that all constexpr
functions are pure functions, because constexpr functions can be used
outside of constant expression evaluation. Let me give you an example:
constexpr int get_and_maybe_log(bool log) {
int value = 100;
if (log) std::cout << "getting value, which is " << value << std::endl;
return value;
}
constexpr int v = get_and_maybe_log(false); // ok, this evaluation is pure
int main() {
return get_and_maybe_log(true); // this is obviously not
}
It doesn't matter how many times you evaluate the expression that
initializes v, you will always get the same answer and never have an
observable side-effect. But get_and_maybe_log is not a pure function.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11439cd0a569a80526f3d311
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 T=
ue, Dec 15, 2015 at 4:37 AM, <span dir=3D"ltr"><<a href=3D"mailto:leni5=
36@gmail.com" target=3D"_blank">leni536@gmail.com</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex">All constexpr evaluation is pure.<br></blockq=
uote><div><br></div></span><div>Are you sure? I found this gem, I wonder if=
it's actually not standard compliant or constexpr functions aren't=
actually pure.</div><div><br></div><div><a href=3D"http://b.atch.se/posts/=
non-constant-constant-expressions/" target=3D"_blank">http://b.atch.se/post=
s/non-constant-constant-expressions/</a></div></div></blockquote><div><br><=
/div><div>Note that the techniques that accomplish this do one of two thing=
s:</div><div><br></div><div>1) Call a different function each time (despite=
using the same function name and arguments), or</div><div>2) Call the func=
tion with different arguments each time (through default arguments that are=
different on subsequent calls)</div><div><br></div><div>But you need to be=
more precise with your words. As Thiago said, "all constexpr evaluati=
on is pure". But that does *not* imply that all constexpr functions ar=
e pure functions, because constexpr functions can be used outside of consta=
nt expression evaluation. Let me give you an example:</div><div><br></div><=
div>constexpr int get_and_maybe_log(bool log) {</div><div>=C2=A0 int value =
=3D 100;</div><div>=C2=A0 if (log) std::cout << "getting value, =
which is " << value << std::endl;</div><div>=C2=A0 return =
value;</div><div>}</div><div><br></div><div>constexpr int v =3D get_and_may=
be_log(false); // ok, this evaluation is pure</div><div>int main() {</div><=
div>=C2=A0 return get_and_maybe_log(true); // this is obviously not</div><d=
iv>}</div><div><br></div><div>It doesn't matter how many times you eval=
uate the expression that initializes v, you will always get the same answer=
and never have an observable side-effect. But get_and_maybe_log is not a p=
ure function.</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" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a11439cd0a569a80526f3d311--
.