TL;DR: "a" must not be a name of an existing function in Qt. On 18.09.23 10:15, Ivan Solovev via Development wrote: > Hi, > > > 1. an ADL-able calling convention: `using std::swap; swap(lhs, rhs);` > > 2. an implementation for built-in types: `std::swap` > > 3. an implementation for user-defined types: ADL `swap` > > 4. (optionally) a convenience wrapper: `std::ranges::swap()`, `qSwap` > > One more question here - do we want our users to be able to do (1), or > is it enough to expose only (4) to them? > The reason for my question is (again) naming, see below.
I see no reason to withhold the like of KDE an API to adapt their types to C++20 semantics while at the same time maintaining compatibility with C++17. But if we can't agree on naming otherwise, then I guess we'll have to make it private and KDE will use it anyway, and everyone will wish we had made it public. > > My original proposal had, for equality, a = equal, b = Qt, c = qEquals, > > and for ordered types, a = order, b = Qt and c = qOrder (or qCompare, > > don't remember which). > > I was about to suggest a = `qt_equals`, b = `Qt`, c = `qEquals`, but that > would result in ugly `Qt::qt_equals()` calls. > > But if we say that the users should only use `qEquals()` and `qCompare` in > their code, then we can use ||`QtPrivate` as the namespace: > a = `qt_equals`, b = `QtPrivate`, c = `qEquals` for equality, and > a = `qt_compare`, b = `QtPrivate`, c = `qCompare` for ordering. > > AFAIK, the most critical drawback of qSwap() was the compilation speed > when having it in every value class, so I would not expect Qt itself to use > `qEquals` and `qCompare` everywhere. > But would it be ok for the user code? > > What do you think? I think that users like KDE that have large Qt-based class libraries and traditionally use our class implementation macros no matter what we say, will want to be treated like a Qt module, so requiring them to only use (4) while we ban the use of (4) in most Qt code, is not going to amuse them. > Other idea that came to my mind while writing this - just do not provide > (4), That is also an option. > since it has known issues (at least with compilation speed). Then we can > use > a = `qEquals`, b = `Qt` for equality, and > a = `qCompare`, b = `Qt` for ordering. > We already have `QTest::qCompare()`, so `Qt::qCompare` would not be > a much worse naming. I don't really want to think about the implications of an ADL-enabled qCompare() on code in the QTest namespace... I don't think we should afford ourselves the inconveniences of unintended overloading. Remember the problem with equals() and compare(): we have classes with these functions, and, regardless of whether they're static or non-static, binary non-member or unary member functions; name lookup will _stop_ at class scope when it finds the name, and it will _not_ continue to look in outer scopes just because the arity or argument types don't match. You will just get a compile error (if lucky) or something unexpected called (if not). Yet, that is exactly what we need for the case where func(A, B) is resolved in terms of func(A, A(B)) (implicit conversions). qCompare() may have the same problem. > Anyway, it would be great to come to some kind of consensus about the > naming of the APIs, and move on to the actual implementation. +1 Thanks, Marc -- Marc Mutz <marc.m...@qt.io> Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
