[Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[André Somers]

Daniel Teske schreef op 19-2-2015 om 13:29:
> Hi,
>
> Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 and
> C++14 added a lot of new good features. C++17 is planned to be a big step
> again.
>
> Qt needs to evolve together with C++ or it will be a outdated toolkit stuck in
> a C++98 world.
>
> As an example, Qt's container classes and C++11 range based for loop do not
> mix very well.[1] And for the same reason, the upcoming Ranges TS will not be
> too useful for Qt's container.
>
> We have started using some parts of C++11 in Creator a year ago and our
> experience is that lambdas (and std::function) are useful everywhere. Today we
> have more than 400 lambdas in Creator's source and have several interfaces
> that take a std::function.
>
> I would expect that allowing C++11 in Qt would similarly lead to a wider
> understanding on how to leverage the new features for better code and better
> APIs.
>
> We need to start now and deprecate old compilers that do not support any C++11
> features at all. I I suggest requiring support for lambda as
> supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating all
> platforms that do not in Qt 5.6.
>
> daniel
>
> [1] ranged based for uses std::begin(container), which if not overloaded calls
> container.begin(), which detaches.
>
> So using range-based can be used:
> - If the container is const or
> - If the container is unshared or
> - To actually change the container's contents
I do get what you mean, and I think they are all valid concerns. But I 
am wondering if the move to support/base Qt API more on top of modern 
C++ developments is not something that belongs in a major release 
instead of a minor one. I think there are quite a few APIs in Qt that 
may need reconsidering in this light. Would it not make more sense to 
introduce a break like that in a major release instead?

Perhaps Qt 6 should not be in the too far future, and might be focused 
on breaking with the pre-C++ 11 heritage? At the same time, Qt 5 might 
be kept alive next to that for a while yet. Not just with bugfixes, but 
with whatever features are still feasible to backport to it.

Question would be: if C++11 support could be dropped, what APIs would 
benefit from being re-designed?

André