------=_Part_1108_2084468099.1493989858838
Content-Type: multipart/alternative;
 boundary="----=_Part_1109_1656569947.1493989858838"

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

According to the latest Draft, `constexpr` is inferred for lambdas:

>  The function call operator or any given operator template specialization=
=20
is a constexpr function if either the corresponding lambdaexpression=E2=80=
=99s=20
parameter-declaration-clause is followed by constexpr, or it satisfies the=
=20
requirements for a constexpr function (7.1.5)

Is there a design rationale or technical reason for not allowing this in=20
the case of regular functions as well?

Andy

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6dc0cc0f-a698-462f-b5fa-a7a9cd2bde09%40isocpp.or=
g.

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

<div dir=3D"ltr">According to the latest Draft, `constexpr` is inferred for=
 lambdas:<div><br></div><div>&gt;=C2=A0 The function call operator
or any given operator template specialization is a constexpr function if ei=
ther the corresponding lambdaexpression=E2=80=99s
parameter-declaration-clause is followed by constexpr, or it satisfies the =
requirements for a
constexpr function (7.1.5)</div><div><br></div><div>Is there a design ratio=
nale or technical reason for not allowing this in the case of regular funct=
ions as well?</div><div><br></div><div>Andy</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6dc0cc0f-a698-462f-b5fa-a7a9cd2bde09%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6dc0cc0f-a698-462f-b5fa-a7a9cd2bde09=
%40isocpp.org</a>.<br />

------=_Part_1109_1656569947.1493989858838--

------=_Part_1108_2084468099.1493989858838--

.

On 5 May 2017 at 16:10, Andy Prowl <andy.prowl@gmail.com> wrote:
> According to the latest Draft, `constexpr` is inferred for lambdas:
>
>>  The function call operator or any given operator template specializatio=
n
>> is a constexpr function if either the corresponding lambdaexpression=E2=
=80=99s
>> parameter-declaration-clause is followed by constexpr, or it satisfies t=
he
>> requirements for a constexpr function (7.1.5)
>
> Is there a design rationale or technical reason for not allowing this in =
the
> case of regular functions as well?


Here's some rationale bits I've been told.

Lambdas are local, and to some extent less likely to be deeply nested. Func=
tions
aren't local. For constant expression evaluation, a compiler needs to
do a lot of work
if it needs to deduce constexprness - and that's not just for the
cases where it would
need to do that work for constant expressions, it would perhaps need to do =
that
work when deciding whether to fold in a context where a constant is
not required, and if it can't fold,
fall back to a non-folding approach.

So some parts of it are implementation complexity concerns, but a
graver concern is that
it might hurt compile times for valid programs.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUY_ybYFi-6jVr1%3D86X%2BjO5h%3DPEcPeBFy%3Dr=
nkH9fWD72Lg%40mail.gmail.com.

.

I'd also like to point to Sebastian's answer on StackOverflow: http://stack=
overflow.com/questions/35309115/why-constexpr-is-not-the-default-for-all-fu=
nction

He explained the rationale from the interface perspective.
=20
> On 5 May 2017, at 22:17, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:
>=20
> On 5 May 2017 at 16:10, Andy Prowl <andy.prowl@gmail.com> wrote:
>> According to the latest Draft, `constexpr` is inferred for lambdas:
>>=20
>>> The function call operator or any given operator template specializatio=
n
>>> is a constexpr function if either the corresponding lambdaexpression=E2=
=80=99s
>>> parameter-declaration-clause is followed by constexpr, or it satisfies =
the
>>> requirements for a constexpr function (7.1.5)
>>=20
>> Is there a design rationale or technical reason for not allowing this in=
 the
>> case of regular functions as well?
>=20
>=20
> Here's some rationale bits I've been told.
>=20
> Lambdas are local, and to some extent less likely to be deeply nested. Fu=
nctions
> aren't local. For constant expression evaluation, a compiler needs to
> do a lot of work
> if it needs to deduce constexprness - and that's not just for the
> cases where it would
> need to do that work for constant expressions, it would perhaps need to d=
o that
> work when deciding whether to fold in a context where a constant is
> not required, and if it can't fold,
> fall back to a non-folding approach.
>=20
> So some parts of it are implementation complexity concerns, but a
> graver concern is that
> it might hurt compile times for valid programs.
>=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=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/CAFk2RUY_ybYFi-6jVr1%3D86X%2BjO5h%3DPEcPeBFy%3=
DrnkH9fWD72Lg%40mail.gmail.com.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/D4D8C8A1-02EA-4E67-9949-C799C645C2BC%40outlook.c=
om.

.