[Development] QUIP 6: removing top-level const from return types

[Marc Mutz]

On 2017-05-24 18:40, Thiago Macieira wrote:
> On Wednesday, 24 May 2017 02:04:36 PDT Lars Knoll wrote:
>> > On 24 May 2017, at 00:35, Giuseppe D'Angelo <dangelog at gmail.com> wrote:
>> >
>> > On Tue, May 23, 2017 at 11:56 PM, Thiago Macieira
>> >
>> > <thiago.macieira at intel.com> wrote:
>> >> We are arguing whether the change makes the code uglier and is worth that
>> >> ugliness. I'm not sold on that. Leave those const behind until Qt 6,
>> >> unless
>> >> you can show that engaging the move constructor is important.
>> >
>> > What about defining a (private) macro centrally and using it in those
>> > places, as it has been proposed?
>> 
>> +1 on that. It avoids the uglyness of having a complicated #ifdef that 
>> we'd
>> probably have in multiple places. It'll also ensure we can do the 
>> changes
>> now and the we won't forget to fix it when we move over to Qt 6.
> 
> "We won't forget when we move to Qt 6" is not an argument. Just add the
> necessary ### Qt6 macro and we won't forget.
> 
> The ### Qt5 that remained in Qt5 weren't because we forgot. It's 
> because they
> were too difficult to apply or broke too much when applied.

I maintain that they were forgotten. Well, or ignored.

 From a quick grep in QtBase, two that caught my eye:

- qvector.h: The solution is obvious, straight-forward, and BiC:
   unexport QPolygon(F). Wasn't done. Wouldn't've broken anything.

- qregexp.cpp: They're also about removing const: from member
   functions, this time. Code breaks, but is trivial to fix.

If we don't even remember to do _that_ kind of trivial change, how can 
we, with a straight face, claim that we will handle all the ### Qt 6 
ones? There are already 236 "### Qt 6" instances today, in QtBase alone. 
They all need to be looked at, understood, maybe re-evaluated, and 
implemented. The ones protected with QT_VERSION checks, otoh, will 
become active the day Ossi flips the switch and calls dev 6.0.0.

Thanks,
Marc