André Pönitz wrote: > I see that pattern, too. But now, instead putting the break between 3) and > 4), the whole thing is killed, and everybody downstream has to do 1)-3) > again, or put up with what the standard offers. > > And could prevent overextension by -x'ing the respective change on gerrit. > So *that* sounds fixable.
But why should Qt let itself be crippled by the STL's limitations? Qt classes being better than STL classes is a GOOD thing. >> * We could keep things where they are, supported, thus offering the >> easier APIs; but simply reimplement them on top of the "upstream" >> equivalents. (Ignore the possible ABI break.) > > The last one is the most reasonable. It is not, because it means Qt can no longer offer features that make it better than the STL. Instead, the Qt implementation should be kept as is. >> Long story short, making qSort() call std::sort() might not have kept the >> behaviour contract with the user. > > *shrug* > > And what if I, as a user, would not care? > > What about https://valdyas.org/fading/hacking/happy-porting/ If you break the contract with the user by silently changing the underlying implementation incompatibly, you also force the user to do porting (e.g., from qLess to std::less). So the user will care. QtAlgorithms should just be undeprecated. I don't care whether std::sort is faster. If the version of Qt I tested with was fast enough, then I'm perfectly fine with newer versions not being faster, no matter how fast some incompatible implementation elsewhere is (and I don't care whether it happens to ship with my compiler or not). Kevin Kofler _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
