[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[André Pönitz]

On Wed, Oct 14, 2015 at 11:15:55AM +0000, Knoll Lars wrote:
> >That leaves classes which simply store the string. You cited QUrl. I
> >don't see 
> >a problem providing QString overloads for these, esp. considering that
> >we're 
> >starting out with an all-QString API here. Then again, once we have
> >QStringView overloads, we can simply disable the QString overloads and
> >see the 
> >effect.
> 
> I think there’s actually quite a few of those. In addition, it might be
> tricky to use QStringView in signals and slots.

One could try to be clever and go through an intermediate QString
object at least in queued connections. Or even always. 

> [...]
> Of course we don’t know all it’s uses. But many uses outside of QtCore are
> clearly less critical. QLineEdit::setText is clearly not called in tight
> loops, and once you set the text it has to do lots of other work. There
> are many similar APIs in Qt, where I don’t think we’ll ever see a benefit
> of a QStringView, and the simplicity of passing in a const QString ref is
> probably preferrable.

Right. OTOH there are instances where it provably *does* matter, e.g.
everything in the vicinity of QFileInfo, or:

> >Take QDateTime as a warning.

...

> I am certainly in favor of experimenting with this. Let’s start in a
> branch or behind an ifdef.

Or in a safer place. See my other mail.

Andre'