Topic: constexpr lambda functions
Author: noreply@firemath.info
Date: Tue, 11 Dec 2012 13:33:15 -0800 (PST)
Raw View
------=_Part_514_1198117.1355261595105
Content-Type: text/plain; charset=ISO-8859-1
I think it would be helpful, if lambda functions could be treated as
constant expressions in some cases. This would make the following code
valid:
struct apply_to_value
{
constexpr
apply_to_value( double val ) : value(val) {}
template<class F>
constexpr double
operator()( F f ) { return f( value ); }
const double value;
};
int main()
{
constexpr auto atv= apply_to_value( 3.2 );
constexpr
double y= atv( [](double x) { return 2.0 * x; } );
}
This might require an extension of the lambda function specification to
allow for an attribute constexpr like in
[](double x)* constexpr* { return 2.0 * x; }
--
------=_Part_514_1198117.1355261595105
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I think it would be helpful, if lambda functions could be treated as consta=
nt expressions in some cases. This would make the following code valid:<br>=
<br>struct apply_to_value<br>{<br> constexpr<br> apply_to_value=
( double val ) : value(val) {}<br> <br> template<class=
F><br> constexpr double<br> operator()( F f ) { retur=
n f( value ); }<br><br> const double value;<br>};<br><br>=
int main()<br>{<br> constexpr auto atv=3D apply_to_value( 3.2 );<br><=
br> constexpr <br> double y=3D atv( [](double x) { return 2.0 *=
x; } );<br>}<br><br>This might require an extension of the lambda function=
specification to allow for an attribute constexpr like in<br><br>[](double=
x)<b> constexpr</b> { return 2.0 * x; } <br><br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_514_1198117.1355261595105--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Tue, 11 Dec 2012 14:41:27 -0800 (PST)
Raw View
------=_Part_401_11923473.1355265687319
Content-Type: text/plain; charset=ISO-8859-1
It would also realistically bring constexpr algorithms, like for_each.
--
------=_Part_401_11923473.1355265687319
Content-Type: text/html; charset=ISO-8859-1
It would also realistically bring constexpr algorithms, like for_each.
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_401_11923473.1355265687319--
.
Author: Alberto Ganesh Barbati <albertobarbati@gmail.com>
Date: Wed, 12 Dec 2012 00:16:37 +0100
Raw View
--Apple-Mail=_CB724994-D886-4A85-86D8-57AD9811083B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
Il giorno 11/dic/2012, alle ore 22:33, noreply@firemath.info ha scritto:
> I think it would be helpful, if lambda functions could be treated as cons=
tant expressions in some cases. This would make the following code valid:
>=20
> struct apply_to_value
> {
> constexpr
> apply_to_value( double val ) : value(val) {}
> =20
> template<class F>
> constexpr double
> operator()( F f ) { return f( value ); }
>=20
> const double value;
> };
>=20
> int main()
> {
> constexpr auto atv=3D apply_to_value( 3.2 );
>=20
> constexpr=20
> double y=3D atv( [](double x) { return 2.0 * x; } );
> }
>=20
> This might require an extension of the lambda function specification to a=
llow for an attribute constexpr like in
>=20
> [](double x) constexpr { return 2.0 * x; }=20
A lambda-expression with no lambda-capture de facto evaluates to a stateles=
s object, so it shouldn't be a problem to treat it as a constant-expression=
.. Its implicit conversion to pointer-to-function could just be declared con=
stexpr (now it's declared const). It would all "just work" and I don't thin=
k we need additional decorations in this case. This could be a nice additio=
n basically for free.
On the other hand, if there's a lambda-capture, the lambda might reasonably=
be constexpr only if all captures are by-copy captures of constexpr locals=
.... I deem this case a bit too remote to be useful, maybe we might just as =
well not even consider it.
Just my two eurocent,
Ganesh
--=20
--Apple-Mail=_CB724994-D886-4A85-86D8-57AD9811083B
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=
=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mo=
de: space; -webkit-line-break: after-white-space; "><br><div><div>Il giorno=
11/dic/2012, alle ore 22:33, <a href=3D"mailto:noreply@firemath.info">nore=
ply@firemath.info</a> ha scritto:</div><br class=3D"Apple-interchange-newli=
ne"><blockquote type=3D"cite">I think it would be helpful, if lambda functi=
ons could be treated as constant expressions in some cases. This would make=
the following code valid:<br><br>struct apply_to_value<br>{<br> cons=
texpr<br> apply_to_value( double val ) : value(val) {}<br> =
; <br> template<class F><br> constexpr double<br>&n=
bsp; operator()( F f ) { return f( value ); }<br><br> const double&nb=
sp; value;<br>};<br><br>int main()<br>{<br> constexpr auto atv=
=3D apply_to_value( 3.2 );<br><br> constexpr <br> double y=3D a=
tv( [](double x) { return 2.0 * x; } );<br>}<br><br>This might require an e=
xtension of the lambda function specification to allow for an attribute con=
stexpr like in<br><br>[](double x)<b> constexpr</b> { return 2.0 * x; } <br=
>
</blockquote><br></div><div>A lambda-expression with no lambda-capture =
;de facto evaluates to a stateless object, so it shouldn't be a proble=
m to treat it as a constant-expression. Its implicit conversion to pointer-=
to-function could just be declared constexpr (now it's declared const). It =
would all "just work" and I don't think we need additional decorations in t=
his case. This could be a nice addition basically for free.</div><div><br><=
/div><div>On the other hand, if there's a lambda-capture, the lambda might =
reasonably be constexpr only if all captures are by-copy captures of conste=
xpr locals... I deem this case a bit too remote to be useful, maybe we migh=
t just as well not even consider it.</div><div><br></div><div>Just my two e=
urocent,</div><div><br></div><div>Ganesh</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
<br />
<br />
--Apple-Mail=_CB724994-D886-4A85-86D8-57AD9811083B--
.
Author: andersgsjogren@gmail.com
Date: Wed, 5 Jun 2013 00:08:10 -0700 (PDT)
Raw View
------=_Part_6470_11843898.1370416090838
Content-Type: text/plain; charset=ISO-8859-1
I think this could indeed be useful for in metaprogramming.
/ Anders
Den onsdagen den 12:e december 2012 kl. 00:16:37 UTC+1 skrev Alberto Ganesh
Barbati:
>
>
> Il giorno 11/dic/2012, alle ore 22:33, nor...@firemath.info <javascript:>ha scritto:
>
> I think it would be helpful, if lambda functions could be treated as
> constant expressions in some cases. This would make the following code
> valid:
>
> struct apply_to_value
> {
> constexpr
> apply_to_value( double val ) : value(val) {}
>
> template<class F>
> constexpr double
> operator()( F f ) { return f( value ); }
>
> const double value;
> };
>
> int main()
> {
> constexpr auto atv= apply_to_value( 3.2 );
>
> constexpr
> double y= atv( [](double x) { return 2.0 * x; } );
> }
>
> This might require an extension of the lambda function specification to
> allow for an attribute constexpr like in
>
> [](double x)* constexpr* { return 2.0 * x; }
>
>
> A lambda-expression with no lambda-capture de facto evaluates to a
> stateless object, so it shouldn't be a problem to treat it as a
> constant-expression. Its implicit conversion to pointer-to-function could
> just be declared constexpr (now it's declared const). It would all "just
> work" and I don't think we need additional decorations in this case. This
> could be a nice addition basically for free.
>
> On the other hand, if there's a lambda-capture, the lambda might
> reasonably be constexpr only if all captures are by-copy captures of
> constexpr locals... I deem this case a bit too remote to be useful, maybe
> we might just as well not even consider it.
>
> Just my two eurocent,
>
> Ganesh
>
>
--
---
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/?hl=en.
------=_Part_6470_11843898.1370416090838
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I think this could indeed be useful for in metaprogramming.<br><br>/ Anders=
<br><br>Den onsdagen den 12:e december 2012 kl. 00:16:37 UTC+1 skrev Albert=
o Ganesh Barbati:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D=
"word-wrap:break-word"><br><div><div>Il giorno 11/dic/2012, alle ore 22:33,=
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"OIXEP-M=
gEGAJ">nor...@firemath.info</a> ha scritto:</div><br><blockquote type=3D"ci=
te">I think it would be helpful, if lambda functions could be treated as co=
nstant expressions in some cases. This would make the following code valid:=
<br><br>struct apply_to_value<br>{<br> constexpr<br> apply_to_v=
alue( double val ) : value(val) {}<br> <br> template<c=
lass F><br> constexpr double<br> operator()( F f ) { r=
eturn f( value ); }<br><br> const double value;<br>};<br>=
<br>int main()<br>{<br> constexpr auto atv=3D apply_to_value( 3.2 );<=
br><br> constexpr <br> double y=3D atv( [](double x) { return 2=
..0 * x; } );<br>}<br><br>This might require an extension of the lambda func=
tion specification to allow for an attribute constexpr like in<br><br>[](do=
uble x)<b> constexpr</b> { return 2.0 * x; } <br>
</blockquote><br></div><div>A lambda-expression with no lambda-capture =
;de facto evaluates to a stateless object, so it shouldn't be a proble=
m to treat it as a constant-expression. Its implicit conversion to pointer-=
to-function could just be declared constexpr (now it's declared const). It =
would all "just work" and I don't think we need additional decorations in t=
his case. This could be a nice addition basically for free.</div><div><br><=
/div><div>On the other hand, if there's a lambda-capture, the lambda might =
reasonably be constexpr only if all captures are by-copy captures of conste=
xpr locals... I deem this case a bit too remote to be useful, maybe we migh=
t just as well not even consider it.</div><div><br></div><div>Just my two e=
urocent,</div><div><br></div><div>Ganesh</div><div><br></div></div></blockq=
uote>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_6470_11843898.1370416090838--
.
Author: theypsilon@gmail.com
Date: Mon, 18 Aug 2014 22:58:56 -0700 (PDT)
Raw View
------=_Part_1617_1527834171.1408427936417
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
This could be useful for a better readability in generic code:
std::enable_if_t<[]{
using type =3D typename blablabla...
using decay =3D std::decay<..
...more complicated type aliases
constexpr bool same =3D std::is_same..
...more complicated constexpr operations
return same && ..
}>
El mi=C3=A9rcoles, 5 de junio de 2013 14:08:10 UTC+7, andersg...@gmail.com=
=20
escribi=C3=B3:
>
> I think this could indeed be useful for in metaprogramming.
>
> / Anders
>
> Den onsdagen den 12:e december 2012 kl. 00:16:37 UTC+1 skrev Alberto=20
> Ganesh Barbati:
>>
>>
>> Il giorno 11/dic/2012, alle ore 22:33, nor...@firemath.info ha scritto:
>>
>> I think it would be helpful, if lambda functions could be treated as=20
>> constant expressions in some cases. This would make the following code=
=20
>> valid:
>>
>> struct apply_to_value
>> {
>> constexpr
>> apply_to_value( double val ) : value(val) {}
>> =20
>> template<class F>
>> constexpr double
>> operator()( F f ) { return f( value ); }
>>
>> const double value;
>> };
>>
>> int main()
>> {
>> constexpr auto atv=3D apply_to_value( 3.2 );
>>
>> constexpr=20
>> double y=3D atv( [](double x) { return 2.0 * x; } );
>> }
>>
>> This might require an extension of the lambda function specification to=
=20
>> allow for an attribute constexpr like in
>>
>> [](double x)* constexpr* { return 2.0 * x; }=20
>>
>>
>> A lambda-expression with no lambda-capture de facto evaluates to a=20
>> stateless object, so it shouldn't be a problem to treat it as a=20
>> constant-expression. Its implicit conversion to pointer-to-function coul=
d=20
>> just be declared constexpr (now it's declared const). It would all "just=
=20
>> work" and I don't think we need additional decorations in this case. Thi=
s=20
>> could be a nice addition basically for free.
>>
>> On the other hand, if there's a lambda-capture, the lambda might=20
>> reasonably be constexpr only if all captures are by-copy captures of=20
>> constexpr locals... I deem this case a bit too remote to be useful, mayb=
e=20
>> we might just as well not even consider it.
>>
>> Just my two eurocent,
>>
>> Ganesh
>>
>>
--=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_1617_1527834171.1408427936417
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This could be useful for a better readability in generic c=
ode:<div><br></div><div>std::enable_if_t<[]{</div><div> usi=
ng type =3D =
typename blablabla...</div><div> using decay &nb=
sp; =3D std::decay<..</div><div><br></=
div><div> ...more complicated type aliases</div><div><br></div=
><div> constexpr bool same =3D std::is_same..</div><div><br></=
div><div> ...more complicated constexpr operations</div><div><=
br></div><div> return same && ..</div><div>}></div>=
<div><br><div><br>El mi=C3=A9rcoles, 5 de junio de 2013 14:08:10 UTC+7, and=
ersg...@gmail.com escribi=C3=B3:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">I think this could indeed be useful for in metaprogramming.<br><br>/ And=
ers<br><br>Den onsdagen den 12:e december 2012 kl. 00:16:37 UTC+1 skrev Alb=
erto Ganesh Barbati:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"w=
ord-wrap:break-word"><br><div><div>Il giorno 11/dic/2012, alle ore 22:33, <=
a>nor...@firemath.info</a> ha scritto:</div><br><blockquote type=3D"cite">I=
think it would be helpful, if lambda functions could be treated as constan=
t expressions in some cases. This would make the following code valid:<br><=
br>struct apply_to_value<br>{<br> constexpr<br> apply_to_value(=
double val ) : value(val) {}<br> <br> template<class =
F><br> constexpr double<br> operator()( F f ) { return=
f( value ); }<br><br> const double value;<br>};<br><br>i=
nt main()<br>{<br> constexpr auto atv=3D apply_to_value( 3.2 );<br><b=
r> constexpr <br> double y=3D atv( [](double x) { return 2.0 * =
x; } );<br>}<br><br>This might require an extension of the lambda function =
specification to allow for an attribute constexpr like in<br><br>[](double =
x)<b> constexpr</b> { return 2.0 * x; } <br>
</blockquote><br></div><div>A lambda-expression with no lambda-capture =
;de facto evaluates to a stateless object, so it shouldn't be a proble=
m to treat it as a constant-expression. Its implicit conversion to pointer-=
to-function could just be declared constexpr (now it's declared const). It =
would all "just work" and I don't think we need additional decorations in t=
his case. This could be a nice addition basically for free.</div><div><br><=
/div><div>On the other hand, if there's a lambda-capture, the lambda might =
reasonably be constexpr only if all captures are by-copy captures of conste=
xpr locals... I deem this case a bit too remote to be useful, maybe we migh=
t just as well not even consider it.</div><div><br></div><div>Just my two e=
urocent,</div><div><br></div><div>Ganesh</div><div><br></div></div></blockq=
uote></blockquote></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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1617_1527834171.1408427936417--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 19 Aug 2014 14:02:25 +0800
Raw View
On 2014-08-19, at 1:58 PM, theypsilon@gmail.com wrote:
> This could be useful for a better readability in generic code:
>
> std::enable_if_t<[]{
Lambda expressions cannot occur in unevaluated contexts such as template arguments, so allowing this would require a separate proposal.
You could define a named constexpr lambda and then call it in the template argument, but you can do that with ordinary constexpr functions already.
--
---
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: David Krauss <potswa@gmail.com>
Date: Tue, 19 Aug 2014 14:05:37 +0800
Raw View
On 2014-08-19, at 2:02 PM, David Krauss <potswa@gmail.com> wrote:
> Lambda expressions cannot occur in unevaluated contexts such as template =
arguments, so allowing this would require a separate proposal.
Oops, template arguments are evaluated (obviously) but not runtime-evaluate=
d, which is effectively the requirement for a context that allows lambda ex=
pressions. (=A75.1.2/2)
--=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/.
.
Author: louis.dionne92@gmail.com
Date: Tue, 19 Aug 2014 06:45:59 -0700 (PDT)
Raw View
------=_Part_359_1479814325.1408455959807
Content-Type: text/plain; charset=UTF-8
One motivation for this feature is the following use case. It is an
efficient
implementation of std::tuple:
template <typename ...Xs>
constexpr auto make_storage(Xs ...xs) {
auto storage = [=](auto f) { return f(xs...); };
return storage;
}
template <typename ...Xs>
struct tuple {
explicit constexpr tuple(Xs ...xs)
: storage{make_storage(xs...)}
{ }
decltype(make_storage(std::declval<Xs>()...)) storage;
};
template <std::size_t n, typename ...T>
constexpr decltype(auto) get(tuple<T...>& t) {
return t.storage([](auto&& ...xs) {
// implementing this efficiently is possible
});
}
As I mention in the above comment, once you get variadic arguments,
accessing
them at any given index can be done in amortized O(1). For that technique,
see
[1] (this is based on [2] by Richard Smith). Here are benchmarks comparing
the
creation of a tuple based on this technique with the `std::tuple` in libc++
trunk. The "hana_list" curve is the above tuple implementation.
http://i.imgur.com/rKqmvk3.png
I also have other use cases for constexpr lambdas in the library [3] I am
currently developping, which is a C++14 metaprogramming library merging
Boost.MPL and Boost.Fusion. It uses several advanced C++14 idioms, some of
which are worth having a look at.
Regards,
Louis Dionne
Note: I also posted this to comp.lang.c++.moderated
<https://groups.google.com/forum/#!topic/comp.lang.c++.moderated/9Fa2Fzlvlxg>
[1]:
https://github.com/ldionne/hana/blob/master/include/boost/hana/detail/variadic/at.hpp
[2]: http://llvm.org/bugs/show_bug.cgi?id=13263
[3]: http://github.com/ldionne/hana
--
---
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_359_1479814325.1408455959807
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
One motivation for this feature is the following use case. It is an ef=
ficient<div>implementation of std::tuple: <br><div><br> t=
emplate <typename ...Xs> <br> constexpr auto make_s=
torage(Xs ...xs) { <br> auto storage =3D [=
=3D](auto f) { return f(xs...); }; <br> ret=
urn storage; <br> } <br><br> template &=
lt;typename ...Xs> <br> struct tuple { <br> =
explicit constexpr tuple(Xs ...xs) <br> &n=
bsp; : storage{make_storage(xs...)} <br>&n=
bsp; { } <br><br> decl=
type(make_storage(std::<wbr>declval<Xs>()...)) storage; <br>&nbs=
p; }; <br><br> template <std::size_t n, typenam=
e ...T> <br> constexpr decltype(auto) get(tuple<T..=
..>& t) { <br> return t.storage([](au=
to&& ...xs) { <br> //=
implementing this efficiently is possible <br> &n=
bsp; }); <br> } <br><br>As I mention in the above co=
mment, once you get variadic arguments, accessing <br>them at any give=
n index can be done in amortized O(1). For that technique, see <br>[1]=
(this is based on [2] by Richard Smith). Here are benchmarks comparing the=
<br>creation of a tuple based on this technique with the `std::tuple`=
in libc++ <br>trunk. The "hana_list" curve is the above tuple impleme=
ntation. <br><br><a href=3D"http://i.imgur.com/rKqmvk3.png" target=3D"=
_blank" style=3D"cursor: pointer;">http://i.imgur.com/rKqmvk3.png</a> =
<br><br>I also have other use cases for constexpr lambdas in the library [3=
] I am <br>currently developping, which is a C++14 metaprogramming lib=
rary merging <br>Boost.MPL and Boost.Fusion. It uses several advanced =
C++14 idioms, some of <br>which are worth having a look at. <br><=
br>Regards, <br>Louis Dionne </div><div><br></div><div>Note: I al=
so posted this to <a href=3D"https://groups.google.com/forum/#!topic/c=
omp.lang.c++.moderated/9Fa2Fzlvlxg">comp.lang.c++.moderated</a><br><br><br>=
[1]: <a href=3D"https://github.com/ldionne/hana/blob/master/include/bo=
ost/hana/detail/variadic/at.hpp" target=3D"_blank" style=3D"cursor: pointer=
;">https://github.com/ldionne/hana/blob/master/include/boost/hana/detail/va=
riadic/at.hpp</a> <br>[2]: <a href=3D"http://llvm.org/bugs/show_b=
ug.cgi?id=3D13263" target=3D"_blank" style=3D"cursor: pointer;">http://llvm=
..org/bugs/show_bug.<wbr>cgi?id=3D13263</a> <br>[3]: <a href=3D"ht=
tp://github.com/ldionne/hana" target=3D"_blank" style=3D"cursor: pointer;">=
http://github.com/ldionne/hana</a> <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_359_1479814325.1408455959807--
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 19 Aug 2014 12:52:19 -0700 (PDT)
Raw View
------=_Part_625_1375992922.1408477939462
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, August 18, 2014 11:05:38 PM UTC-7, David Krauss wrote:
>
>
> On 2014=E2=80=9308=E2=80=9319, at 2:02 PM, David Krauss <pot...@gmail.com=
<javascript:>>=20
> wrote:=20
>
> > Lambda expressions cannot occur in unevaluated contexts such as templat=
e=20
> arguments, so allowing this would require a separate proposal.=20
>
> Oops, template arguments are evaluated (obviously) but not=20
> runtime-evaluated, which is effectively the requirement for a context tha=
t=20
> allows lambda expressions. (=C2=A75.1.2/2)=20
>
>
I personally think that lambda expressions should be allowed in unevaluated=
=20
contexts, so long as the end result to whatever non-evaluating=20
operator/context is not a lambda. In other words, sizeof([](int x) {=20
return x + 4; }) would be ill-formed, but sizeof([](int x) { return x + 4;=
=20
}()) would not be, since that would just be sizeof(int). This would be=20
subject to the restriction that such lambdas met all the rules of a=20
constexpr function.
What was the original motivation of disallowing lambdas in unevaluated=20
context?
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/.
------=_Part_625_1375992922.1408477939462
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, August 18, 2014 11:05:38 PM UTC-7, Davi=
d Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>On 2014=E2=80=9308=E2=80=9319, at 2:02 PM, David Krauss <<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"iEf4GuyGJNAJ" onmou=
sedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">pot...@gmail.com</a>> wrote:
<br>
<br>> Lambda expressions cannot occur in unevaluated contexts such as te=
mplate arguments, so allowing this would require a separate proposal.
<br>
<br>Oops, template arguments are evaluated (obviously) but not runtime-eval=
uated, which is effectively the requirement for a context that allows lambd=
a expressions. (=C2=A75.1.2/2)
<br>
<br></blockquote><div><br>I personally think that lambda expressions should=
be allowed in unevaluated contexts, so long as the end result to whatever =
non-evaluating operator/context is not a lambda. In other words, <spa=
n style=3D"font-family: courier new,monospace;">sizeof([](int x) { return x=
+ 4; })</span> would be ill-formed, but <span style=3D"font-family: courie=
r new,monospace;">sizeof([](int x) { return x + 4; }())</span> would not be=
, since that would just be <span style=3D"font-family: courier new,monospac=
e;">sizeof(int)</span>. This would be subject to the restriction that=
such lambdas met all the rules of a <span style=3D"font-family: courier ne=
w,monospace;">constexpr</span> function.<br><br>What was the original motiv=
ation of disallowing lambdas in unevaluated context?<br><br>Melissa<br></di=
v></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_625_1375992922.1408477939462--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 19 Aug 2014 23:07:35 +0300
Raw View
On 19 August 2014 22:52, Myriachan <myriachan@gmail.com> wrote:
> What was the original motivation of disallowing lambdas in unevaluated
> context?
I don't remember what other sorts of problems it causes, but it would
be rather hard to
grasp for many people that in
decltype([]{})* a;
decltype([]{})* b;
and any of its ilk, a and b would have different types.
Just because lambdas can't appear in unevaluated contexts has nothing to do with
whether we should have constexpr lambdas. A template argument is not
an unevaluated
context. And as you suggest, there's a difference between a lambda
appearing in an unevaluated
context at all, and just invoking a lambda in one, although we might
still want to keep things
simple and keep the ban.
--
---
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/.
.