Polymorphic lambdas?
Mathias Gaunard
chance for polymorphic lambdas to be included in C++0x.
What is the status of that? Is it going to be in or not? Or will we
just have monomorphic lambdas as we have in the current draft?
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Ville Voutilainen
> When the drop of concepts was announced, some people said it gave a
> chance for polymorphic lambdas to be included in C++0x.
> What is the status of that? Is it going to be in or not? Or will we
> just have monomorphic lambdas as we have in the current draft?
I don't believe polymorphic lambdas can make it into C++0x. The
schedule is tight enough
and there are several people who will oppose any feature additions at
this late stage. I
haven't heard about even a proposal to add them, so this sounds like
unsubstantiated rumour
regarding C++.
Scott Meyers
> On Dec 21 2009, 5:59 am, Mathias Gaunard <loufo...@gmail.com> wrote:
>> When the drop of concepts was announced, some people said it gave a
>> chance for polymorphic lambdas to be included in C++0x.
>> What is the status of that? Is it going to be in or not? Or will we
>> just have monomorphic lambdas as we have in the current draft?
>
> I don't believe polymorphic lambdas can make it into C++0x.
I suspect you're right, but I think this is a terrible shame -- a grotesque wart
on the lambda interface. What I find particularly frustrating is that I have
not been able to find any information about why this restriction exists. N1968
( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf ) by
Jeremiah Willcock, Jaakko J�rvi, Doug Gregor, Bjarne Stroustrup, and Andrew
Lumsdaine -- people who certainly understand lambdas -- says
> We considered the possibility of supporting polymorphic lambda functions,
> whose parameter types need not be specified. Such a lambda function would
> implicitly be an unconstrained template, accepting any argument types; the
> body would be checked against the particular argument types used when the
> call to the lambda function is instantiated. Such functions would not
> create significant difficulties for the proposed translation model. A
> lambda expression whose parameter types were not specified would simply be
> translated to a function object whose function call operator is a
> template. Such lambda functions would, however, clash with the modular
> type-checking which we attempt to introduce to C++ via concepts [SD05,
> GSW+05].
This suggests that the removal of concepts would also remove the primary
technical objection to polymorphic lambdas. Boost lambdas are polymorphic, and
N1968 observes:
> A possible argument in favor of providing polymorphic lambda functions is
> that the existing bind and lambda libraries only provide (unconstrained)
> polymorphic lambda functions.
Does anybody know of technical reasons why we can't just say
[](auto x) { ... }
and have the resulting closure simply declare its operator() as a template?
Scott
Mathias Gaunard
> I think this is a terrible shame -- a grotesque wart
> on the lambda interface. What I find particularly frustrating is that I
have
> not been able to find any information about why this restriction exists.
N1968
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf) by
> Jeremiah Willcock, Jaakko J rvi, Doug Gregor, Bjarne Stroustrup, and
Andrew
> Lumsdaine -- people who certainly understand lambdas -- says
>
> > We considered the possibility of supporting polymorphic lambda
functions,
> > whose parameter types need not be specified. Such a lambda function
would
> > implicitly be an unconstrained template, accepting any argument types;
the
> > body would be checked against the particular argument types used when
the
> > call to the lambda function is instantiated.
That is actually somewhat incorrect. The template would be constrained
by the return value type, which in the case of your average lambda
function is automatically deduced.
[](x) { return x+1; }
would generate a function like
template<typename T>
auto f(T x) -> decltype(x+1) { return x+1; }
By virtue of SFINAE, this makes the function f constrained to types
for which the expression "x+1" doesn't result in an error. Just like
concepts, instead they are automatically deduced.
This is actually very elegant and similar to the full-fledged type
inference functional programming languages do.
This would make lambdas really useful and game changing for very
little to actually add to the standard.
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use
mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>
Scott Meyers
>
> That is actually somewhat incorrect. The template would be constrained
> by the return value type, which in the case of your average lambda
> function is automatically deduced.
>
> [](x) { return x+1; }
>
> would generate a function like
>
> template<typename T>
> auto f(T x) -> decltype(x+1) { return x+1; }
I don't know if you meant to do this, but I really like that you
omitted the "auto" declaration for x. It makes lambdas even terser,
and while I'm normally not a big terseness fan, in the case of
lambdas, I think they become more useful the less syntactic heft they
carry. Lambdas already have implicit return types (most of the time),
and parameterless lambdas already may have implicit parameter lists
(most of the time), so allowing lambda parameters to have an implicit
type of "auto" would fit right in. Except that the standardization
committee inexplicably refuses to permit polymorphic lambdas.
Scott
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
Miles Bader
> Except that the standardization
> committee inexplicably refuses to permit polymorphic lambdas.
Do you know if there's actual _resistance_ to them, or just a sort of
"OMG if we make any more changes, it'll _never_ be done" attitude...?
Would the discussed polymorphic lambda syntax be an straight-forward
extension of the current non-polymorphic lambda syntax (for a future
standard or whatever), or are they somehow incompatible?
Thanks,
-Miles
--
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread.
Scott Meyers
> Do you know if there's actual _resistance_ to them, or just a sort of
> "OMG if we make any more changes, it'll _never_ be done" attitude...?
I don't know. I don't expect lambdas to be changed at this late date, but I
would really like to know why polymorphic lambdas appear to not have been
reconsidered after concepts were canned.
> Would the discussed polymorphic lambda syntax be an straight-forward
> extension of the current non-polymorphic lambda syntax (for a future
> standard or whatever), or are they somehow incompatible?
My guess is that it'd be a straight extension, but the problem with guesses is
that they can overlook important technical issues. The experience with
Boost.Lambda suggests that polymorphic lambdas don't have any implementation
difficulties, but it'd be nice to hear something from somebody who
actually knows.
Scott
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use
mailto:std...@netlab.cs.rpi.edu <std-c%2B%2...@netlab.cs.rpi.edu>]
Francis Glassborow
> Scott Meyers <Neve...@aristeia.com> writes:
>
>> Except that the standardization
>> committee inexplicably refuses to permit polymorphic lambdas.
>>
>
> Do you know if there's actual _resistance_ to them, or just a sort of
> "OMG if we make any more changes, it'll _never_ be done" attitude...?
>
> Would the discussed polymorphic lambda syntax be an straight-forward
> extension of the current non-polymorphic lambda syntax (for a future
> standard or whatever), or are they somehow incompatible?
>
> Thanks,
>
> -Miles
>
My memory is that when we discussed this we decided to err on the side of
caution and leave polymorphic lambdas for next time. We also hoped that by
then there would be actual implementations available as extensions.
When dealing with these kinds of changes to C++ it is easy to get
overwhelmed and become concerned that we might be taking one step too many.
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use
mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>
Scott Meyers
> My memory is that when we discussed this we decided to err on the side of
y
> then there would be actual implementations available as extensions.
This would be a more convincing argument were it not for the existence of
Boost.Lambda, which offers polymorphic lambda expressions. The syntax is n=
ot
that of C++0x, of course, but one would certainly hope that the usage
experience
would be largely applicable. Furthermore, it seems that the authors of N19=
68
(including Jaakko J=E4rvi, whom one would expect to be exceedingly familiar=
with
the issues involved) didn't see any technical implementation problems
associated
with polymorphic lambdas. N1968 also points out that Boost.bind (which is
essentially the same as TR1 bind and C++0x bind) has offered a templatized
operator() for years.
In this case, trotting out the "we wanted to err on the side of
caution until we
have more experience" argument doesn't seem very effective, at least not fo=
r me.
Scott
Francis Glassborow
> Miles Bader wrote:
>
>> Do you know if there's actual _resistance_ to them, or just a sort of
>> "OMG if we make any more changes, it'll _never_ be done" attitude...?
>>
>
> I don't know. I don't expect lambdas to be changed at this late date, but
> I
> would really like to know why polymorphic lambdas appear to not have been
> reconsidered after concepts were canned.
>
Because WG21 did not want to open the door to further reconsideration of a
raft of other things however desirable. The toughest problem for WG21 has
been rejecting or shelving excallent ideas and proposals.
> Would the discussed polymorphic lambda syntax be an straight-forward
>> extension of the current non-polymorphic lambda syntax (for a future
>> standard or whatever), or are they somehow incompatible?
>>
>
> My guess is that it'd be a straight extension, but the problem with guesses
> is
> that they can overlook important technical issues. The experience with
> Boost.Lambda suggests that polymorphic lambdas don't have any
> implementation
> difficulties, but it'd be nice to hear something from somebody who
> actually knows.
>
> Scott
>
>
--
Note that robinton.demon.co.uk addresses are no longer valid.
Mathias Gaunard
> Furthermore, it seems that the authors of N19=
> 68
> (including Jaakko J=E4rvi, whom one would expect to be exceedingly familiar=
> with
> the issues involved) didn't see any technical implementation problems
> associated
> with polymorphic lambdas.
I can see one problem though : local classes may not have template
members; and aren't the types generated by lambda expressions supposed
to be local?
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
Scott Meyers
> I can see one problem though : local classes may not have template
> members; and aren't the types generated by lambda expressions supposed
> to be local?
Yep. Does anybody know why local classes are not permitted to have member
templates?
Scott
Sergey S.
On Jan 22, 9:27 pm, Scott Meyers <NeverR...@aristeia.com> wrote:
> Yep. Does anybody know why local classes are not permitted to have member
> templates?
>
> Scott
>
The same question:
http://groups.google.com/group/comp.std.c++/browse_thread/thread/7ea0cc54e0bb8d7c?hl=en#
------------
Best regards,
Sergey.
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use
mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>
Faisal Vali
> Mathias Gaunard wrote:
> > I can see one problem though : local classes may not have template
> > members; and aren't the types generated by lambda expressions supposed
> > to be local?
>
> Yep. Does anybody know why local classes are not permitted to have member
> templates?
>
When I submitted this as a defect report over a year ago, it had to be
relegated to "Extension" Status.
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#728
I'm not sure what the technical difficulties are either, but then I
don't write compilers ;)
regards,
Faisal Vali
Radiation Oncology
Loyola