[Development] Challenge: adding new method overloads when existing consumers use {} with args

[A. Pönitz]

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'