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

[Björn Breitmeyer]

Regarding the bloat,

why not add the new functions and mark the old ones as deprecated. Of course
it bloats the default. But it would also mean we know which functions will 
vanish encourage people not to use deprecated functions for old code and
have a compile option that doesn't compile deprecated code(Maybe that exists 
already).

-- 
Björn Breitmeyer | bjoern.breitmeyer at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Germany: +49-30-521325470, Sweden (HQ): +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions 
Am Freitag, 20. Februar 2015, 10:04:31 schrieb André Somers:
> Bo Thorsen schreef op 20-2-2015 om 09:03:
> > Andrés question about how this would change the API is a lot more
> > interesting. I so far haven't seen a single case where someone has
> > described how access to lambdas might improve the API. If they are
> > there, I'd love to see them, because maybe this would teach me
> > something I haven't figured out yet.
> 
> One example I could come up with as a potential new API is
> QSortFilterProxyModel. Currently, it requires subclassing to change the
> sort or the filter functions: it supplies protected filterAcceptsRow,
> filterAcceptsColumn and lessThan functions. I think that it would be
> much more convenient if these filters and the comparator could be
> supplied as a function object (a lambda, or a functor, or a std::mem_fn,
> anything callable as a function). While this wasn't all that practical
> in the past, I think C++/11 makes this much more convenient than
> subclassing.
> 
> This could of course just be added, instead of replacing. But that would
> mean API bloat. Downside of replacing is of course: you break old code.
> 
> I think that if we go over the Qt classes, we'll find more examples of
> where a subclass or a separate function that you need to write could be
> replaced with a more modern API.
> 
> André
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5920 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150220/e58b8ce6/attachment.bin>