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

Lars Knoll lars.knoll at qt.io
Mon May 22 21:54:02 CEST 2017


On 22 May 2017, at 20:14, André Pönitz <apoenitz at t-online.de<mailto: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 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 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/ 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.

Cheers,
Lars

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170522/5f8c920b/attachment.html>


More information about the Development mailing list