On Sat, Jul 30, 2022 at 01:10:55PM +0200, Giuseppe D'Angelo via Development wrote: > 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!
This is a context that in my book clearly does not justify source incompatibility: This code typically run once per dialog/whatever instantation, waiting for further user interaction. A copy of the string contents with a few dozen or even hundreds of characters is completely acceptable under such circumstances. Andre' _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
