On 13/05/2020 02.33, Lars Knoll wrote:
On 12 May 2020, at 23:09, Thiago Macieira wrote:
I want rules that determine what the API should be without looking at the
implementation of those two functions.
You may be disappointed, at least as far as parameters.
This is one reason why I think we should simply use QString in most of those
cases.
Additionally, QString is a class that owns it’s data, making it the
class that’s easiest to use and safest. QStringView doesn’t own it’s
data and as such there are always lifetime considerations that need
to be taken into account when using it. So using it would make using
the API harder and more error prone.
That might be true for return values. For parameters, if the *user*
needs to care whether the function takes a QString vs. QStringView,
we're doing something wrong. The onus to properly handle a QStringView
in that case should be entirely on the *implementer* of the API.
...but yeah, if we're talking about return values, that's a whole other
kettle of fish.
--
Matthew
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
