C++ standart is a software and like any software, it has bugs. It’s good that «auto_ptr» bug was fixed among with auto a {42};
However, reading the dev list it seems that people claim that *everything* that is done by the Committee is a bug and there’s only the «Qt way» of doing things like it was back in Qt4 days. If Qt wants to stay alive, it should adopt to the changes in C++ where reasonable. Sorry, I can’t buy an argument «we should always return a copy of a container because someday somewhere in KDE was a bug and the copy helped to solve it». Why we should force the way of doing things for the 1% case? Maybe we should force the way suitable for 99% cases and solve that 1% case in the other way? Like add a new function foo2 with new signature? > 20 мая 2019 г., в 22:10, André Pönitz <apoen...@t-online.de> написал(а): > > At some time The Commitee decided to standardize auto_ptr, but not > {shared,unique,...}_ptr. People calling auto_ptr unusable for most > practical purposed were chastised for not seeing the light. A while > later The Committee changed their opinion... > > Andre' > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development What’s wrong with qFind(foo(), x); ? I actually have a strong feeling that Ranges will solve that problem too adding something like std::find(Range, T value); Having std::begin(), std::visit() and std::get() it doesn’t seem that bad idea to have a free functions for *everything* If someone don’t like the std::vector::empty() method, he can use qIsEmpty(T) function. Problem solved? > 20 мая 2019 г., в 22:18, André Pönitz <apoen...@t-online.de> написал(а): > > > Exhibit A: > > foo().contains(x) > > > Exhibit B: > > { > ... container = foo(); > std::find(container.begin(), container.end(), x) != container.end(); > } > > > Andre' > > > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development