[Development] QUIP 6: removing top-level const from return types
marc.mutz at kdab.com
Mon May 22 23:05:46 CEST 2017
On 2017-05-22 21:54, Lars Knoll wrote:
>> On 22 May 2017, at 20:14, André Pönitz <apoenitz at t-online.de>
>> 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:
>> 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  proposes to add it to
>> the QUIP.
>> Precedence: E.g. https://codereview.qt-project.org/93161 
>> 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
>> 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
> 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/ 
> -const QPixmap QSplashScreen::pixmap() const
> +#if !defined(Q_QDOC) && defined(Q_COMPILER_MANGLES_RETURN_TYPE) &&
> QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
> ++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
> 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.
More information about the Development