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

[Rafael Roquetto]

Hi Daniel,

On Thu, Feb 19, 2015 at 01:29:48PM +0100, Daniel Teske wrote:
> 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.

Agreed, but there is no free lunch. See below.

> 
> 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.

That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a
relatively new release), and BlackBerries. I personally would have loved to
remove support for 6.5.0, since it is based on an old gcc version that can
barely keep up with latest C++ developments (and keep giving me maintenance
headaches from time to time). But strategically (read, comercially) speaking,
this is still not possible - QNX 6.5.0 is still widely deployed.
The move to 6.6.0 is happening at a slow pace - probably much slower
than the time it will take us to reach Qt 5.7. One of the many reasons for
that is that many of those systems running QNX are homologated and
changing/upgrading involves lots of different process apart from the technical
stuff.

While I am not for keeping Qt stuck in the last century, I think a
more sensible move would be to actually analyze how far we can push it given
the current major platforms Qt is being used on, in other words, follow the
market, and also take into account the trade-off of dropping platforms that
generate revenue in the form of trainings, services, commercial licensing and
last but not least, code contributions. I am taking QNX as an example because
this is the platform I am familiar with, but I guess this could also affect
other platforms such as Windows CE.

Just my opinion.

Thanks,
Rafael

-- 
Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4861 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150219/2ffbd808/attachment.bin>