[Development] User-defined literals for QString (and QByteArray)
André Pönitz
Andre.Poenitz at qt.io
Tue Mar 9 07:42:24 CET 2021
> Ville Voutilainen <ville.voutilainen at gmail.com>
> On Fri, 5 Mar 2021 at 14:26, Giuseppe D'Angelo via Development
> <development at qt-project.org> wrote:
> >
> > Il 05/03/21 12:08, Tor Arne Vestbø ha scritto:
> > > This seems like a bug though? From an API point of view, I’d expect this
> > > simple assignment to JustWorkTM, without requiring syntactic sugar all
> > > over the place. Shouldn’t we fix this, so we don’t need (or leave
> > > optional) an explicit _qs suffix?
> >
> > Because of
> >
> > void f(QString);
> > void f(QStringView);
> > f(u"foobar"); // ambiguous
> >
> > combined with the overarching plan of adding QStringView overloads when
> > possible (that is, in functions where historically we weren't doing so)
> > and never breaking BC/SC.
> Right. Somethings gotta give, and if QString and QStringView are
> implicitly convertible from the same things,
> those calls are ambiguous, and there's nothing that can be done about
> that unless the overload set f decides which
> one it prefers.
> Compromising the implicit convertibility would allow us to make one of
> those functions preferable, but that would
> mean that all conversions to one of those types need to be explicit.
> At which point the syntax you want to work doesn't
> work. The ambiguity doesn't prevent it from working, though - but if
> we don't want that ambiguity, we need to make
> either of QString or QStringView not-implicitly-convertible from a literal.
> Like in this little playground: https://wandbox.org/permlink/mjAdAI56GCjBXhjJ
What if there weren't overloads of the actual functions on QString and
QStringView?
https://wandbox.org/permlink/rdIhbPRdGHuWWxFW
Andre'
More information about the Development
mailing list