[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Giuseppe D'Angelo]

On 08/06/2019 21:39, Konstantin Tokarev wrote:
>>
>> What abouthttps://valdyas.org/fading/hacking/happy-porting/
>>
>>     "[...] none, not a single one of all of the reasons you want to deprecate
>>     Q_FOREACH is a reason I care even a little bit about. It’s going to
>>     be deprecated? Well, that’s a decision, and a dumb one. It doesn’t
>>     work on std containers, QVarLengthArray or C arrays? I don’t use
>>     it on those. It adds 100 bytes of text size? Piffle. It makes it hard
>>     to reason about the loop for you? I don’t care.
>>
>>     What I do care is the 1559 places where we use Q_FOREACH in Krita.
>>     Porting this will take weeks. [...]"
>>
>> ?
> This kind of porting could be automated with clang-based tool, if anyone cared to
> make it. This tool could automatically use qAsConst/std::as_const for non-const
> lvalues and add temporary variable for non-const rvalues, without user even
> knowing what the hell are lvalues and rvalues and other things Marc writes about.
> 
> 

At the cost of saying for the 100th time, before this stuff ends up 
indexed by Google: you can port away from Q_FOREACH in an automated way 
only in trivial cases. *NOT* in the general case.

For the general case you've only got the 5 minutes solution (c&p&rename 
Q_FOREACH into your codebase; assuming the worst case, of lack of 
"Qt5Support" or so) or the long walk of checking all usages.

HTH,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190610/02cc128e/attachment.bin>