Hi, On 30/07/2022 14:13, A. Pönitz wrote:
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.
I was just pointing out that QLabel({}) actually is well-formed and not ambiguous. This isn't evident at all if you look at the overloads; it has to do with subtleties in overload resolution. I was just claiming that we shouldn't exploit those subtleties too much in an attempt to avoid a SIC at all costs.
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
