ahmadsamir added a comment.
In D23902#542046 <https://phabricator.kde.org/D23902#542046>, @dfaure wrote: > In D23902#542037 <https://phabricator.kde.org/D23902#542037>, @ahmadsamir wrote: > > > In D23902#542026 <https://phabricator.kde.org/D23902#542026>, @dfaure wrote: > > > > > For the record, JFBastien was actually wrong. Calling .begin() on a const return value does call the const overload. Testcase http://www.davidfaure.fr/kde/const_retval.cpp > > > > > > That looks like a failure in communication, either one of you _assumed_ something but didn't tell the other. :D > > > You and I are both entitled to our own opinion, I know what I asked and what the reply was :-P > (I tried to reach him afterwards via linkedin and cppcon slack, no success) > > >> But returning const QList would inhibit move semantics, e.g. `QList<int> mylist = foo();` copies instead of moving. > >> So yeah, better not do that. > > > > And it would detach (I don't know why it feels like detaching for Qt containers is like a sword hanging over all, especially new, developers' heads; so implicit sharing is great, except you have to worry about the container detaching for the rest of its natural life... :)). > > No, a copy doesn't detach. A non-const method call on a copy detaches. See? I actually was talking about calling a non-const method, begin(), on a non-const Qt container (or a copy of it), that would make it detach even if it never gets actually modified in the loop, that's what I was thinking in my head. So I _assumed_ it got the point across but because I posted that right under your post about move semantics that kicked the point out the window; so you assumed I was talking about move semantics. Assumptions are bad, man I am telling you.... :) > And usually you don't have to worry about that. Detaching happens when it should, i.e. when modifying a copy, that's intended. The problem is range-for, which came up later, and which throws ease-of-use a little bit out of the window indeed. Well, I _guess_ the devs who wrote the range for code did that with STL containers in mind, where you're OK if you don't change the container _size_ (IIUC). They probably weren't thinking about the implicitly shared containers created by the Qt devs? Anyway, thanks for sharing. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D23902 To: ahmadsamir, kde-frameworks-devel, dfaure Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
