On Wed, 13 May 2020 at 12:50, Tor Arne Vestbø <tor.arne.ves...@qt.io> wrote:
>
>
>
> > On 13 May 2020, at 10:12, Edward Welbourne <edward.welbou...@qt.io> wrote:
> >
> >> Note that adding the QString(char16_t*) constructor introduces this
> >> ambiguity for the functions that are already overloaded on
> >> QString+QStringView (and thus today are using QStringView).
> >
> > Would it suffice to skip the QString(char16_t *) constructor and,
> > instead, have a QString(QStringView) constructor ?
> >
> > I guess calls to functions taking QString would have to make one of the
> > steps explicit, when passing a u"...", i.e. either call
> > f(QString(u"...")) or f(QStringView(u"...")), preferring the latter (as
> > it's future-proof against f changing signature from QString to
> > QStingView later; note that this concern applies to Qt-using code, which
> > may allow itself such ABI-breaks, not just Qt itself, which wouldn't, at
> > least not once the old API has appeared in a public release).  I suppose
> > both forms are capable of exploiting constexpr and happening at
> > compile-time, when the compiler deigns to make it so.
>
> Whatever we end up with, _please_ avoid the 
> explicitness/verboseness/boilerplate of having to wrap every “foo” in some 
> QPreferredStringTypeOfTheWeek(“foo”)
>
> I expect my code to looks like this:
>
>   foo.bar(“baz”)
>
> Or if the allocations and conversations are really a performance issue for 
> this particular piece of code:
>
>  foo.bar(u“baz”)
>
> Anything else should be reserved for corner cases where the explicitness is 
> warranted.

That's all well and good, but if foo.bar(a) and foo.bar(b) have
different semantics on whether
the class copies or views what I pass in, I am going to hurt you. :)
Meaning that if it sometimes
stores a copy, then it should always store a copy, instead of
sometimes storing a copy
and sometimes storing a view, in which case I need to be insanely
careful about calling
such functionality. If the class doesn't store the argument, I don't
care. If it does, it should
decide whether it stores a copy or a view.

Overloads in an overload set should have the same semantics,
otherwise that API is a vector<bool>, where for some incoming types it
does A and for others
it does B, and the code can no longer be read without looking at the
API documentation for every call.
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to