[Development] User-defined literals for QString (and QByteArray)

Andrei Golubev andrei.golubev at qt.io
Fri Mar 5 13:51:51 CET 2021


That said, QByteArray's ctor accepting char* is not explicit (which kind of makes sense) and we have this ambiguity for f(QByteArray) and f(QByteArrayView) I believe. But guessing that it's not expected that QByteArrayView would be as popular as QStringView.
Thus, QByteArray str = "hello" works fine, so maybe no need to introduce a UDL for that class. OTOH, QString and QByteArray would have API differences (in some sense) yet again (and there's QByteArrayLiteral).

--
Best Regards,
Andrei
________________________________
From: Development <development-bounces at qt-project.org> on behalf of Ville Voutilainen <ville.voutilainen at gmail.com>
Sent: Friday, March 5, 2021 1:38 PM
To: Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>
Cc: Qt development mailing list <development at qt-project.org>
Subject: Re: [Development] User-defined literals for QString (and QByteArray)

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
_______________________________________________
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20210305/c0d41fab/attachment-0001.html>


More information about the Development mailing list