Topic: constexpr in the era of modules.
Author: =?UTF-8?Q?Germ=C3=A1n_Diago?= <germandiago@gmail.com>
Date: Sun, 9 Aug 2015 20:54:12 -0700 (PDT)
Raw View
------=_Part_315_801578824.1439178852096
Content-Type: multipart/alternative;
boundary="----=_Part_316_910157672.1439178852096"
------=_Part_316_910157672.1439178852096
Content-Type: text/plain; charset=UTF-8
Hello everyone,
I still have some concerns about constexpr functions that I think I raised
before.
The goal of this post is to make people think if a solution would be
possible, why it would or would not be possible.
My questions are:
I keep looking at the D language and its compile-time function execution.
It needs to request the compile-time calculation
only at call site (not at declaration site):
1.- In the era of modules, can we get away with constexpr in function
declarations in some way, or we will still need them
forever?
Annotating everything with constexpr is really noisy: but constexpr
calculation can be useful in any context, at any time.
Regards
--
---
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_316_910157672.1439178852096
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello everyone,<br><br>I still have some concerns about co=
nstexpr functions that I think I raised before.<br><br>The goal of this pos=
t is to make people think if a solution would be possible, why it would or =
would not be possible.<br><br>My questions are:<br><br><br><br>I keep looki=
ng at the D language and its compile-time function execution. It needs to r=
equest the compile-time calculation<br>only at call site (not at declaratio=
n site):<br><br>1.- In the era of modules, can we get away with constexpr i=
n function declarations in some way, or we will still need them<br>forever?=
<br><br>Annotating everything with constexpr is really noisy: but constexpr=
calculation can be useful in any context, at any time.<br><br>Regards<br><=
/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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_316_910157672.1439178852096--
------=_Part_315_801578824.1439178852096--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 10 Aug 2015 15:19:58 +0800
Raw View
--Apple-Mail=_8385C028-7F28-4807-A1CF-44044A886361
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9308=E2=80=9310, at 11:54 AM, Germ=C3=A1n Diago <germandiag=
o@gmail.com> wrote:
>=20
> I keep looking at the D language and its compile-time function execution.=
It needs to request the compile-time calculation
> only at call site (not at declaration site):
Perhaps enlighten any readers of this list who may be curious?
> 1.- In the era of modules, can we get away with constexpr in function dec=
larations in some way, or we will still need them
> forever?
Are we now in the era of modules? Why would they make a difference?
It would be nice to see a paper describing the scope of the Modules TS. Pas=
t discussions on this list have summed it up as a system for essentially al=
lowing multiple precompiled headers, but the official papers describe a rad=
ical bottom-up redesign, making it hard to tell what=E2=80=99s really chang=
ed.
For what it=E2=80=99s worth, N4465 =C2=A74.9 says:
> 4.9 Constexpr and Inline Functions
>=20
> We propose no fundamental change to the rules governing constexpr or inli=
ne functions. Any exported constexpr or inline function must be defined in =
the module unit providing the interface of the owning module. The definitio=
n itself need not be exported.=20
>=20
I gather that this means you cannot define a constexpr function in a .cpp f=
ile, but the language is abstruse. A =E2=80=9Cmodule unit=E2=80=9D is a tra=
nslation unit according to =C2=A73.2 of the same paper, but apparently this=
includes erstwhile headers as well as implementation sources. The export k=
eyword need not modify the definition because it=E2=80=99s not conceptually=
considered part of the module interface, but it=E2=80=99s still treated as=
part of the module interface (i.e. exported) anyway.
I gather that modules still use file-level dependency tracking, so changing=
any non-exported content in a module unit will still incur the recompilati=
on of every module unit that imports it. Therefore an interface file typica=
lly wouldn=E2=80=99t have anything at all outside the export block, such as=
function definitions.
> Annotating everything with constexpr is really noisy: but constexpr calcu=
lation can be useful in any context, at any time.
The problem is that constexpr is fundamentally an opt-in feature. See this =
<http://stackoverflow.com/a/19830673/153285> StackOverflow Q&A which summar=
izes this <https://groups.google.com/a/isocpp.org/d/msg/std-discussion/nrAu=
_YbCbYM/0eQsx6ip1DwJ> std-discussion thread. Additionally, if you look at t=
he other answers to the StackOverflow question, the community consensus see=
ms to be that constexpr isn=E2=80=99t noise but a useful annotation.
I vaguely recall suggesting extern "constexpr" {} scope on this list, withi=
n which all declarations are implicitly constexpr. The reaction was that it=
would only improve writability at the expense of readability.
--=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=_8385C028-7F28-4807-A1CF-44044A886361
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9308=
=E2=80=9310, at 11:54 AM, Germ=C3=A1n Diago <<a href=3D"mailto:germandia=
go@gmail.com" class=3D"">germandiago@gmail.com</a>> wrote:</div><br clas=
s=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""=
>I keep looking at the D language and its compile-time function execution. =
It needs to request the compile-time calculation<br class=3D"">only at call=
site (not at declaration site):<br class=3D""></div></div></blockquote><di=
v><br class=3D""></div><div>Perhaps enlighten any readers of this list who =
may be curious?</div><br class=3D""><blockquote type=3D"cite" class=3D""><d=
iv class=3D""><div dir=3D"ltr" class=3D"">1.- In the era of modules, can we=
get away with constexpr in function declarations in some way, or we will s=
till need them<br class=3D"">forever?<br class=3D""></div></div></blockquot=
e><div><br class=3D""></div><div>Are we now in the era of modules? Why woul=
d they make a difference?</div><div><br class=3D""></div><div>It would be n=
ice to see a paper describing the scope of the Modules TS. Past discussions=
on this list have summed it up as a system for essentially allowing multip=
le precompiled headers, but the official papers describe a radical bottom-u=
p redesign, making it hard to tell what=E2=80=99s really changed.</div><div=
><br class=3D""></div><div>For what it=E2=80=99s worth, N4465 =C2=A74.9 say=
s:</div><div><blockquote type=3D"cite" class=3D"">
=09
=09
=09
=09
=09
<div class=3D"page" title=3D"Page 16">
<div class=3D"layoutArea">
<div class=3D"column"><p class=3D""><span style=3D"font-size: 12pt; fon=
t-family: NimbusRomNo9L; color: rgb(64, 128, 128);" class=3D"">4.9 Constexp=
r and Inline Functions
</span></p><p class=3D""><span style=3D"font-size: 11.000000pt; font-family=
: 'NimbusRomNo9L'" class=3D"">We propose </span><span style=3D"font-size: 1=
1.000000pt; font-family: 'NimbusRomNo9L'; font-style: italic" class=3D"">no=
</span><span style=3D"font-size: 11.000000pt; font-family: 'NimbusRomNo9L'=
" class=3D"">fundamental change to the rules governing constexpr or inline =
functions. Any exported constexpr or inline function must be defined in the=
module unit
providing the interface of the owning module. The definition itself need no=
t be exported. </span></p>
</div>
</div>
</div></blockquote></div><div>I gather that this means you cannot define =
a constexpr function in a <font face=3D"Courier" class=3D"">.cpp</font> fil=
e, but the language is abstruse. A =E2=80=9Cmodule unit=E2=80=9D is a trans=
lation unit according to =C2=A73.2 of the same paper, but apparently this i=
ncludes erstwhile headers as well as implementation sources. The <font face=
=3D"Courier" class=3D"">export</font> keyword need not modify the definitio=
n because it=E2=80=99s not conceptually considered part of the module inter=
face, but it=E2=80=99s still treated as part of the module interface (i.e. =
exported) anyway.</div><div><br class=3D""></div><div>I gather that modules=
still use file-level dependency tracking, so changing any non-exported con=
tent in a module unit will still incur the recompilation of every module un=
it that imports it. Therefore an interface file typically wouldn=
=E2=80=99t have anything at all outside the <font face=3D"Courier" class=3D=
"">export</font> block, such as function definitions.</div><div><br class=
=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=
=3D"ltr" class=3D"">Annotating everything with constexpr is really noisy: b=
ut constexpr calculation can be useful in any context, at any time.<br clas=
s=3D""></div></div></blockquote></div><br class=3D""><div class=3D"">The pr=
oblem is that constexpr is fundamentally an opt-in feature. See <a hre=
f=3D"http://stackoverflow.com/a/19830673/153285" class=3D"">this</a> S=
tackOverflow Q&A which summarizes <a href=3D"https://groups.google=
..com/a/isocpp.org/d/msg/std-discussion/nrAu_YbCbYM/0eQsx6ip1DwJ" class=3D""=
>this</a> std-discussion thread. Additionally, if you look at the othe=
r answers to the StackOverflow question, the community consensus seems to b=
e that constexpr isn=E2=80=99t noise but a useful annotation.</div><div cla=
ss=3D""><br class=3D""></div><div class=3D"">I vaguely recall suggesting <f=
ont face=3D"Courier" class=3D"">extern "constexpr" {}</font> scop=
e on this list, within which all declarations are implicitly constexpr. The=
reaction was that it would only improve writability at the expense of read=
ability.</div><div class=3D""><br class=3D""></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" 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=_8385C028-7F28-4807-A1CF-44044A886361--
.
Author: german.diago@hubblehome.com
Date: Mon, 10 Aug 2015 04:27:53 -0700 (PDT)
Raw View
------=_Part_709_1473440368.1439206073310
Content-Type: multipart/alternative;
boundary="----=_Part_710_416932772.1439206073311"
------=_Part_710_416932772.1439206073311
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
"The community consensus seems to be that constexpr isn=E2=80=99t noise but=
a=20
useful annotation."
Well, I understand the severe limitations or that it may be technically=20
unfeasible, but as a function annotation, I do not see
how it could be useful, since a function could most of the time be=20
"potentially constexpr".=20
If you have all functions, or at least inline functions, as potentially=20
"constexpr" without the need to mark them as such, only at the call
site you would need this.=20
It is the way the D language does this and I do not see an inconvenience in=
=20
not marking
those functions as constexpr. Of course the case for C++ seems to not be=20
the same, but I think that
we should target that ideal as close as possible.
In D they just say:
enum auto val =3D myFunc();
and get it done.
--=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_710_416932772.1439206073311
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">"The community consensus seems to be that constexpr i=
sn=E2=80=99t noise but a useful annotation."<br><br>Well, I understand=
the severe limitations or that it may be technically unfeasible, but as a =
function annotation, I do not see<br>how it could be useful, since a functi=
on could most of the time be "potentially constexpr". <br><br>If =
you have all functions, or at least inline functions, as potentially "=
constexpr" without the need to mark them as such, only at the call<br>=
site you would need this. <br><br>It is the way the D language does this an=
d I do not see an inconvenience in not marking<br>those functions as conste=
xpr. Of course the case for C++ seems to not be the same, but I think that<=
br>we should target that ideal as close as possible.<br><br>In D they just =
say:<br><br>enum auto val =3D myFunc();<br><br>and get it done.<br></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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_710_416932772.1439206073311--
------=_Part_709_1473440368.1439206073310--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 10 Aug 2015 20:14:25 +0800
Raw View
--Apple-Mail=_8981BCA6-500E-4BD7-8FFB-0E595BDB5431
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9308=E2=80=9310, at 7:27 PM, german.diago@hubblehome.com wr=
ote:
>=20
> "The community consensus seems to be that constexpr isn=E2=80=99t noise b=
ut a useful annotation."
>=20
> Well, I understand the severe limitations or that it may be technically u=
nfeasible, but as a function annotation, I do not see
> how it could be useful, since a function could most of the time be "poten=
tially constexpr".=20
As the Q&A shows, I tend to agree with you, against the majority. At least,=
when writing a constexpr metaprogramming library or a computation of some =
nontrivial constant data structures, it=E2=80=99s noisy to mark every singl=
e declaration as constexpr. That was the motivation of my constexpr block s=
cope suggestion. Maybe, once the issue has come up for more people, a propo=
sal will find support.
I don=E2=80=99t think I=E2=80=99d advise anyone to just mark every function=
as constexpr indiscriminately.
> In D they just say:
>=20
> enum auto val =3D myFunc();
>=20
> and get it done.
That=E2=80=99s not quite the same. C++ constexpr allows opportunistic evalu=
ation in non-constant expression contexts as well. It might cause trouble (=
slow compile times, reduced compiler stability) to have the compiler specul=
atively evaluating every expression, even functions of nontrivial complexit=
y that weren=E2=80=99t intended for compile time.
--=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=_8981BCA6-500E-4BD7-8FFB-0E595BDB5431
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9308=
=E2=80=9310, at 7:27 PM, <a href=3D"mailto:german.diago@hubblehome.com" cla=
ss=3D"">german.diago@hubblehome.com</a> wrote:</div><br class=3D"Apple-inte=
rchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">"The community=
consensus seems to be that constexpr isn=E2=80=99t noise but a useful anno=
tation."<br class=3D""><br class=3D"">Well, I understand the severe limitat=
ions or that it may be technically unfeasible, but as a function annotation=
, I do not see<br class=3D"">how it could be useful, since a function could=
most of the time be "potentially constexpr". <br class=3D""></div></div></=
blockquote><div><br class=3D""></div><div>As the Q&A shows, I tend to a=
gree with you, against the majority. At least, when writing a constexpr met=
aprogramming library or a computation of some nontrivial constant data stru=
ctures, it=E2=80=99s noisy to mark every single declaration as constexpr. T=
hat was the motivation of my constexpr block scope suggestion. Maybe, once =
the issue has come up for more people, a proposal will find support.</div><=
div><br class=3D""></div><div>I don=E2=80=99t think I=E2=80=99d advise anyo=
ne to just mark every function as <font face=3D"Courier" class=3D"">constex=
pr</font> indiscriminately.</div><br class=3D""><blockquote type=3D"cite" c=
lass=3D""><div class=3D""><div dir=3D"ltr" class=3D"">In D they just say:<b=
r class=3D""><br class=3D"">enum auto val =3D myFunc();<br class=3D""><br c=
lass=3D"">and get it done.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>That=E2=80=99s not quite the same. C++ constexpr allo=
ws opportunistic evaluation in non-constant expression contexts as well. It=
might cause trouble (slow compile times, reduced compiler stability) to ha=
ve the compiler speculatively evaluating every expression, even functions o=
f nontrivial complexity that weren=E2=80=99t intended for compile time.</di=
v></div><br class=3D""></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" 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=_8981BCA6-500E-4BD7-8FFB-0E595BDB5431--
.
Author: german.diago@hubblehome.com
Date: Mon, 10 Aug 2015 18:57:09 -0700 (PDT)
Raw View
------=_Part_1471_1598552982.1439258230049
Content-Type: multipart/alternative;
boundary="----=_Part_1472_1331869123.1439258230049"
------=_Part_1472_1331869123.1439258230049
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> That=E2=80=99s not quite the same. C++ constexpr allows opportunistic eva=
luation=20
> in non-constant expression contexts as well. It might cause trouble (slow=
=20
> compile times, reduced compiler stability) to have the compiler=20
> speculatively evaluating every expression, even functions of nontrivial=
=20
> complexity that weren=E2=80=99t intended for compile time.
>
>
As far as I know, the same is true for D. You can remove enum and have the=
=20
result at run-time. What is the difference?=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_1472_1331869123.1439258230049
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div styl=
e=3D"word-wrap:break-word"><div><div>That=E2=80=99s not quite the same. C++=
constexpr allows opportunistic evaluation in non-constant expression conte=
xts as well. It might cause trouble (slow compile times, reduced compiler s=
tability) to have the compiler speculatively evaluating every expression, e=
ven functions of nontrivial complexity that weren=E2=80=99t intended for co=
mpile time.</div></div><br></div></blockquote><div><br>As far as I know, th=
e same is true for D. You can remove enum and have the result at run-time. =
What is the difference? <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" 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_1472_1331869123.1439258230049--
------=_Part_1471_1598552982.1439258230049--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 11 Aug 2015 10:28:56 +0800
Raw View
--Apple-Mail=_57B906CB-675A-42DA-A4D6-44CE453FF01A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9308=E2=80=9311, at 9:57 AM, german.diago@hubblehome.com wr=
ote:
>=20
>=20
> That=E2=80=99s not quite the same. C++ constexpr allows opportunistic eva=
luation in non-constant expression contexts as well. It might cause trouble=
(slow compile times, reduced compiler stability) to have the compiler spec=
ulatively evaluating every expression, even functions of nontrivial complex=
ity that weren=E2=80=99t intended for compile time.
>=20
>=20
> As far as I know, the same is true for D. You can remove enum and have th=
e result at run-time. What is the difference?=20
In C++, without the enum, the result may still be determined at compile tim=
e. It=E2=80=99s just no longer guaranteed to happen at compile time. A C++ =
compiler can statically track which expressions are potentially constant, a=
nd it=E2=80=99s not too wasteful to attempt to evaluate all of them. The co=
nstexpr function specifier may be key to that.
On the other hand, perhaps the D compiler does the same. I hardly know anyt=
hing about that language, much less its implementation.
--=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=_57B906CB-675A-42DA-A4D6-44CE453FF01A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9308=
=E2=80=9311, at 9:57 AM, <a href=3D"mailto:german.diago@hubblehome.com" cla=
ss=3D"">german.diago@hubblehome.com</a> wrote:</div><br class=3D"Apple-inte=
rchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><br class=3D""=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break=
-word" class=3D""><div class=3D""><div class=3D"">That=E2=80=99s not quite =
the same. C++ constexpr allows opportunistic evaluation in non-constant exp=
ression contexts as well. It might cause trouble (slow compile times, reduc=
ed compiler stability) to have the compiler speculatively evaluating every =
expression, even functions of nontrivial complexity that weren=E2=80=99t in=
tended for compile time.</div></div><br class=3D""></div></blockquote><div =
class=3D""><br class=3D"">As far as I know, the same is true for D. You can=
remove enum and have the result at run-time. What is the difference? <br c=
lass=3D""></div></div></div></blockquote><div><br class=3D""></div><div>In =
C++, without the <font face=3D"Courier" class=3D"">enum</font>, the re=
sult may still be determined at compile time. It=E2=80=99s just no longer&n=
bsp;<i class=3D"">guaranteed</i> to happen at compile time. A C++ compiler =
can statically track which expressions are potentially constant, and it=E2=
=80=99s not too wasteful to attempt to evaluate all of them. The <font face=
=3D"Courier" class=3D"">constexpr</font> function specifier may be key to t=
hat.</div></div><br class=3D""><div class=3D"">On the other hand, perhaps t=
he D compiler does the same. I hardly know anything about that language, mu=
ch less its implementation.</div><div class=3D""><br class=3D""></div></bod=
y></html>
<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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_57B906CB-675A-42DA-A4D6-44CE453FF01A--
.