<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 20, 2019 at 11:32 PM Mutz, Marc via Development <<a href="mailto:development@qt-project.org">development@qt-project.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
All I'm saying is that there are tons of examples (QGradient) where the <br>
use of an owning container in the API is just a very bad idea and limits <br>
the implementor's freedom and/or performance. E.g. QGradient could have <br>
inline storage for two or three stops to avoid allocating memory for the <br>
most-common cases. I mean, QPainter is full of (QPoint *, int nPoints) <br>
APIs that surely were added just for performance. Ditto for QString, <br>
btw. Nowadays, with views, we can have the same API, but have it accept <br>
many owning containers transparently. I'm not saying that there must be <br>
no owning containers in the API. But there is a lot of low-hanging fruit <br>
out there.<br></blockquote><div><br>Okay, I can live with that, and I do see why it'd make sense in some cases to iterate the data directly. But then as a container can have many different iterables, it seems reasonable to consider adding a couple of methods that return views and take it from there. Why the push to remove the owning container(s) API? In time it may prove you're right, so then we can migrate the getters to the view API and eventually deprecate these methods. Or they could coexist, or w/e. The point is why reach for the top if there's low-hanging fruit?<br></div></div></div>