On 28/07/2022 22:54, Thiago Macieira wrote:
This case can be considered a Category B source incompatible change as per https://quips-qt-io.herokuapp.com/quip-0006.html, because it clearly introduces ambiguity.But {} is particularly special, so I don't know how we'd deal with it. I don't think this has come up for us yet. For one, the mailing list thread linked in the QUIP didn't address it.
Generally speaking, we try to avoid overloading when possible (but use differently named functions), although there are situations in which we just don't/can't (e.g. constructors):
QQmlContext *ctx = new QQmlContext({}); // ERROR, ambiguous
Ultimately, I think that we simply don't "really" deal with this
particular problem, and may accept the SIC. For instance, if we add a
QStringView overload to a function taking QString, this is a SIC but I
don't think we would reject the addition. I certainly don't think we
should do super-clever stuff. (E.g.: QLabel has these two constructors:
QLabel(const QString &text, QWidget *parent = nullptr, Qt::WindowFlags f = Qt::WindowFlags()) > QLabel(QWidget *parent = nullptr, Qt::WindowFlags f = Qt::WindowFlags())
However:
QLabel *label = new QLabel({}); // compiles!
"Unicorn" initialization.)... having said that, I can also see scenarios where we would in fact reject the addition if it creates a "gratuitous" SIC. For instance right now there's a
QPoint &operator+=(QPoint)
Someone proposed to add
QPoint &operator+=(QSize)
But that would make p += {deltax, deltay} ambiguous, for very little reason.
My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
