[Interest] Qt API annoyances: where to log/discuss?

[Giuseppe D'Angelo]

Il 22/11/18 10:03, Dmitriy Purgin ha scritto:
> 
> On Thu, Nov 1, 2018 at 3:44 PM Giuseppe D'Angelo via Interest 
> <interest at qt-project.org <mailto:interest at qt-project.org>> 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.

Side note: the One Ranges Proposal has been ratified in San Diego for 
inclusion in C++20:

> https://herbsutter.com/2018/11/13/trip-report-fall-iso-c-standards-meeting-san-diego/
There isn't a "why we can't", except of course that someone needs to do 
the work -- work that is already being done elsewhere, and that we could 
just use.


> 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.

That's correct, but this isn't an argument for not using ranges-v3 or 
Boost.Ranges, which are available today, work on all major platforms, 
are widely documented, tested, discussed, and so on.


> 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. 

This is an argument which is heard very often, and not just towards Qt 
-- for instance it's heard when trying to get $something into the 
Standard Library, so that one has high quality, no extra dependencies, 
(usually) same licensing than the compiler, and so on.

The other side of this argument is: Qt can't provide you with 
_everything_. The development bandwidth is finite, and therefore Qt's 
scope is limited. Which brings back the question: is it worth for the Qt 
project to invest efforts in areas that are being already covered (in an 
excellent way) by other libraries?

My 2 c,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20181127/c5524758/attachment.bin>