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

[Marc Mutz]

On 2017-05-22 21:54, Lars Knoll wrote:
>> On 22 May 2017, at 20:14, André Pönitz <apoenitz at t-online.de>
>> wrote:
>> 
>> On Mon, May 22, 2017 at 04:14:59PM +0200, Olivier Goffart wrote:
>> Am Montag, 22. Mai 2017, 12:04:10 CEST schrieb Marc Mutz:
>> Hi,
>> 
>> Removing top-level const from return types is a QUIP-6 Cat-A SiC,
>> but was
>> missing from the examples.
>> 
>> https://codereview.qt-project.org/195285 [1] proposes to add it to
>> the QUIP.
>> 
>> Precedence: E.g. https://codereview.qt-project.org/93161 [2]
>> 
>> I think it's fine to break SiC in this case.
>> 
>> Maybe we can have a QT_RETURNED_CONST_TYPE macro that would be
>> defined to
>> "const" iff Q_COMPILER_MANGLES_RETURN_TYPE is defined, or nothing
>> otherwise.
>> 
>> That way one would just write:
>> 
>> QT_RETURNED_CONST_TYPE QPixmap pixmap() const;
>> 
>> and we would avoid any #ifdef
> 
>  That would be sensible and at least would remove part of the
> cosmetical
>  atrocity this patch introduces.
> 
>  Note, however, that it was not this change that caused the current
>  controversy, but https://codereview.qt-project.org/#/c/195229/ [3]
> i.e.
> 
>  -const QPixmap QSplashScreen::pixmap() const
>  +#if !defined(Q_QDOC) && defined(Q_COMPILER_MANGLES_RETURN_TYPE) &&
> QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
>  +const
>  +#endif
>  ++QPixmap QSplashScreen::pixmap() const
> 
>  This introduces three lines of compiler-dependent #ifdef-ery
>  - in a rarely used function
>  - in a not-exactly-widely-used class
>  - for absolutely no user-visible gain.
> 
>  I do not want the Qt code base develop into a direction where common
>  activities like "declaring a trivial getter" are hidden behind a
>  Jmulti-line preprocessor mess.
> 
>  If *that* code style is considered acceptable we do have a serious
>  problem.
> 
>  I have to agree with Andre here. The three line #ifdef'ery above is
> something I would only want to do if there is no other solution to a
> real problem getting Qt to compile.
> 
> Removing the const from the returned pixmap here is mainly cosmetic,
> and I really haven't seen any reason why we couldn't delay changing
> this to Qt 6. We can of prepare already now by adding a macro that
> expands to const in Qt 5 and will trigger a compile error (or expand
> to empty) in Qt 6.

The point is that this completely foils the purpose of QUIP-6, namely to 
have objective rules for (acceptable) SiCs. So we do _not_ have to deal 
with this unproductive subjective nonsense all the time. As one of the 
very few who actually deals with such API bugs, I can tell you that 
these opinionated "discussions" are a real drag on both productivity and 
motivation. These three lines _will_ _be_ _gone_ by Qt 6. Friedemann had 
certainly no problem reviewing them. There's really no reason for making 
such a fuss about it. None whatsoever. I look 5-10 years into the 
future. I suggest others to start doing the same. Maybe then you will 
come to the same conclusion, namely that that bit of temporary ifdefery 
is perfectly ok, esp. if the work has _already_ _been_ _done_.

As for the macro, yeah, let's add it. We have 
Q_DECLARE_SHARED_NOT_MOVABLE_UNTIL_QT6, after all. The question is, of 
course, how many users that macro will see. Without more users, that 
will only move he #ifdefs to somewhere else. Because I, for one, will 
most certainly _not_ touch const return values anymore after this. And 
everyone else doesn't care.

Thanks,
Marc