Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-14 Thread Marc Mutz via Development
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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-14 Thread Ulf Hermann via Development
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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-14 Thread Thiago Macieira
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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-14 Thread Giuseppe D'Angelo via Development
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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-14 Thread A . Pönitz
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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-14 Thread Thiago Macieira
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-

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-14 Thread Marc Mutz via Development
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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-14 Thread Volker Hilsheimer via Development
> 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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-14 Thread Marc Mutz via Development
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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-14 Thread Thiago Macieira
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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-14 Thread Volker Hilsheimer via Development
> 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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-14 Thread Ulf Hermann via Development
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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-14 Thread Marc Mutz via Development
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

Re: [Development] (was: Re: C++20 @ Qt)

2022-11-14 Thread Marc Mutz via Development
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