On 15.11.22 03:32, Giuseppe D'Angelo via Development wrote:
>
> We've found a robust solution to this problem via the removed_api
> mechanism, which is going to keep the QString overload, but hide it from
> clients. (At least, I *think*.) This will make calls passing u""
> literals to keep work
So, if the method immediately converts whatever it gets to QList or
QString, then there is no point in passing it a span or view.
My point is that there _is_. Citing my blog post:
callConsumeQStringHelloWorld():
> [...]
That's the worst case scenario of passing an 8bit string literal to a
On Monday, 14 November 2022 18:32:36 PST Giuseppe D'Angelo via Development
wrote:
> I'm not sure what is meant here. I was just pointing out that
> overloading a function with QString and QStringView (or QAnyStringView
> for that matter) is just a historical accident:
>
> * we have an "old" API t
Il 10/11/22 20:27, Thiago Macieira ha scritto:
(We end up with these overload sets because right now we have tons of
f(QString), and we're slowly moving them to f(QStringView) if it does
make sense for them. Due to the BC promise we can't just_remove_
f(QString).)
And we shouldn't. So we shouldn
On Mon, Nov 14, 2022 at 04:54:20PM +, Volker Hilsheimer wrote:
>
> > On 12 Nov 2022, at 14:41, A. Pönitz wrote:
> >
> > On Fri, Nov 11, 2022 at 09:35:27AM +0100, Ulf Hermann via
> > Development wrote:
> >> There is an undeniable benefit of _offering_ QSpan, QStringView,
> >> and generator AP
On Monday, 14 November 2022 12:53:19 PST Marc Mutz via Development wrote:
> > I don't think we will ever change return types.
>
> Your short interjections would be more valuable if you didn't just state
> an opinion, but also give rationale ;-)
That's why I said "I think".
We can't return a non-
On 14.11.22 18:11, Thiago Macieira wrote:
> On Monday, 14 November 2022 08:22:44 PST Marc Mutz via Development wrote:
>> Can we agree that NOI for setters is a no-brainer? Then 90% of the
>> usefulness of NOI can already be reaped, in a BC and SC manner. There's
>> pretty little we can do with retu
> On 14 Nov 2022, at 18:30, Marc Mutz via Development
> wrote:
>
> Hi Ulf,
>
> On 14.11.22 17:37, Ulf Hermann via Development wrote:
>> Hi Marc,
>>
>>> On 11.11.22 09:35, Ulf Hermann via Development wrote:
There is an undeniable benefit of _offering_ QSpan, QStringView, and
generat
Hi Ulf,
On 14.11.22 17:37, Ulf Hermann via Development wrote:
> Hi Marc,
>
>> On 11.11.22 09:35, Ulf Hermann via Development wrote:
>>> There is an undeniable benefit of _offering_ QSpan, QStringView, and
>>> generator APIs in a few relevant cases:
>>>
>>> 1. Users want to pass a "foreign" contai
On Monday, 14 November 2022 08:22:44 PST Marc Mutz via Development wrote:
> Can we agree that NOI for setters is a no-brainer? Then 90% of the
> usefulness of NOI can already be reaped, in a BC and SC manner. There's
> pretty little we can do with return values before Qt 7, except use the
> stuff i
> On 12 Nov 2022, at 14:41, A. Pönitz wrote:
>
> On Fri, Nov 11, 2022 at 09:35:27AM +0100, Ulf Hermann via Development wrote:
>> There is an undeniable benefit of _offering_ QSpan, QStringView, and
>> generator APIs in a few relevant cases:
>
> This is true, but my problem with this is that alr
Hi Marc,
On 11.11.22 09:35, Ulf Hermann via Development wrote:
There is an undeniable benefit of _offering_ QSpan, QStringView, and
generator APIs in a few relevant cases:
1. Users want to pass a "foreign" container to a Qt function that
doesn't only store it as QList or QString. It might mere
Hi Ulf,
On 11.11.22 09:35, Ulf Hermann via Development wrote:
> There is an undeniable benefit of _offering_ QSpan, QStringView, and
> generator APIs in a few relevant cases:
>
> 1. Users want to pass a "foreign" container to a Qt function that
> doesn't only store it as QList or QString. It mi
On 12.11.22 14:32, Giuseppe D'Angelo via Development wrote:
> I'm not sure if this has been explicitly discussed, but a prerequisite
> for this scheme to work is that compiler vendors *do not* define library
> feature macros inside that you cannot use in the current C++
> version. In other word
14 matches
Mail list logo