[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