On Monday, 14 August 2023 03:16:37 PDT Ivan Solovev via Development wrote: > > What I meant is that the product API of using the macros are the set of > > operators. The methods that those operators called are not API and users > > are not expected to use them in their code. In fact, if conflicting names > > are a problem, then we should uglify the names we're asking for in the > > macros by inserting a "q_" or "qt_" prefix. > > > > This means C++17 users are able to use all operators to produce a boolean > > result, but can't get a QXxxOrdering result with homogeneous API from the > > macros. > > The new macros are supposed to be publicly available. This means that the > users will be able to use them in their custom classes to implement the > unified comparison behavior between C++17 and C++20. > > This means that the users will need to provide their implementations of > the helper methods. The idea is to explicitly mention it in the docs, > so the methods cannot be considered "Qt internal" anymore. > Can we use the "q_" or "qt_" prefix for these helper functions in this case?
The methods aren't "Qt internal" but they they don't have to be API either for those libraries any more than they have to for us. They are used by library implementers (like us), so an uglier name is not a big deal. But maybe we should opt for a name like qHash and the older qLess. > Or do you suggest making the macros Qt-private? Not that we *really* can > do it, because the macros are exposed in public headers, but we can at least > hide the documentation, and do not advertise the macros... > But IMO such decision would significantly decrease the value of the new > feature. I'm unsure. How widely used is this going to be even inside Qt? Have you found any use for it inside Qt Creator? I can actually see this more used in the KF6 libraries than in Qt Creator because they are libraries (Qt Creator has some, but they are all internal with in-tree users). We may want to keep them documented with \internal for the first release and take a look if we find uses for it outside of Qt. That way we can also collect any issues with colliding symbol names and adapt them before having to guarantee source compatibility. > > We still need *some* level of public API to produce ordering results > > because users will need those methods to produce their own comparison > > functions, such as composing on top of our string or date/time classes. > > If they want to also be compatible with C++17, then they can't use the > > spaceship, and instead they will need to call a named function of some > > sorts. If we are going to expose API, then said API must have proper > > names and thus must be "equals" and "compare". > > The initial idea was that the helper functions could also become the public > API for producing ordering results. IIUC, that's also why Marc suggested to > make them hidden friends. Using private 2-arg static function would work for > the comparison operators but wouldn't work as a public API. Hidden friends > will work for both cases. And I think it's a good idea for there to be a public function users can use in C++17 mode. But as I said, that requires them to have proper names. Whether they are the same functions that the macros call is up for debate. They don't have to be: one set can call the other without trouble, just with a bit of boilerplate. The question to answer is whether we want to support users writing generic code in C++17 mode (i.e., without the spaceship). I don't particularly think it's necessary and thus don't think it compels us to make compromises in our API for this use-case. Third party code would either need to require C++20 or forego the ability to be generic. So like above: I think we need to know whether there's any real use out there of this. If we do think we should provide a generic API, then I'd argue such API should be namespaced with a "q" prefix: qEquals and qCompare (note: we have QTest::qCompare, but I don't think there's any clash). > If we advertise only the public API which is not supported by the macros, > then the users will still need to implement all six (or 12 in case of > mixed-type comparison) relational operators instead of just calling one > macro and implementing two helper functions. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
