On Thu, Nov 1, 2018 at 3:44 PM Giuseppe D'Angelo via Interest < [email protected]> wrote:
> And every time you use C++ you have the Standard Library with you, which > (crossing fingers) will have ranges in C++2a; why should Qt spend any > time at all implementing something like that? > > I can't agree with this argument. I can't see why we can't have a Qt-way of processing containers/ranges in a more "functional" way because the standard will _maybe_ have it in future. As you say yourself, we may or we may not have the ranges in C++2a. If we are lucky and we do, it will be 2020 at earliest that the standard is published, and another year or two until all the major compilers keep up and stop consider the C++2a features "experimental", which is, by the way, still the case for gcc and C++17 [1]. So we're looking at 2-4 years from now at best until all these features are "stable" and we can safely use them without risk of having to accidentally debug the standard library or a compiler bug for days. The ranges-v3 library is fine and usable, but by using it in a customer project one has to consider additional dependencies, licenses, portability, maintainability, correctness of the library and its long-term support. The authors state themselves that the library is experimental and subject to change. One of the reasons Qt is so successful is that "it has it all", it's well documented, it generally can be seen as a single dependency, and you generally expect good quality and portability between supported platforms. If I'd see an implementation of ranges-like algorithms in the Qt framework I wouldn't hesitate to use it because I expect it to be at least Qt-grade quality. Of course, as you said earlier, I could implement it myself and propose it to the Qt Framework, but that's not the issue I wanted to addess. [1] https://gcc.gnu.org/projects/cxx-status.html Cheers & regards Dmitriy Purgin
_______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
