> Ville Voutilainen <[email protected]> > On Fri, 5 Mar 2021 at 14:26, Giuseppe D'Angelo via Development > <[email protected]> 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' _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
