> Sent: Thursday, May 25, 2017 at 7:03 PM
> From: "André Somers" <[email protected]>
> To: "Christoph Feck" <[email protected]>
> Cc: [email protected]
> Subject: Re: [Development] QList
>
> Hi,
> 
> Sent from my phone, please excuse my brevity
> 
> > On 25 May 2017, at 18:40, Christoph Feck <[email protected]> wrote:
> > 
> >> On 25.05.2017 13:53, André Somers wrote:
> >> Op 25/05/2017 om 12:38 schreef Konstantin Tokarev:
> >>> Other problem, that IMO is more serious, is that Qt *requires* user to 
> >>> use QList,
> >>> by returning or taking it as and argument in various places. That's 
> >>> almost only
> >>> reason why I use QList in my code[*].
> >>> 
> >>> If Qt 6 APIs are changed from QList to QVector, lots of user code dealing 
> >>> with
> >>> this APIs will break, unless QList will become an alias of QVector.
> >>> 
> >>> [*] And, fwiw, almost only reason I use QString, but that's off-topic here
> >>> 
> >> I think you bring up a good point there. Would not the best way out be
> >> to fix exactly this problem? If these functions would not return a
> >> container, but some type of view into such a container, that would leave
> >> users free to choose the type of container they need for their job
> >> instead of being forced into the direction Qt choose for its API. A view
> >> might take the form of a pair of iterators, a range, or perhaps even
> >> some specialized class that basicaly wraps a pair or iterators and that
> >> provides convenience functions to/from the Qt containers.
> > 
> > If you only return a view to the container, then if the container is 
> > modified, the return value is no longer valid. Returning a full container 
> > (referenced, with copy-on-write semantics) will not have this problem.
> 
> Sure, but do you always or even most of the time need that feature? If not, 
> why always pay for it? And it would be easy to turn it into a container when 
> needed, but then you can choose the most appropriate for your task instead of 
> always getting a QList (now) or a QVector (Qt6?)




I wonder how gsl::span plays into this. I just learned about span, quick seems 
to be wet we need here?












 
> André
> 
> > _______________________________________________
> > Development mailing list
> > [email protected]
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> _______________________________________________
> Development mailing list
> [email protected]
> http://lists.qt-project.org/mailman/listinfo/development
>
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to