Tend to agree with Ville, it would be easier to adopt std::partial_ordering with a proper class in place. Also, you can use std::optional<int> internally in that class as an underlying storage for the result or/and have a conversion operator to std::optional<int> if this is a much desired return type, right?
-- Best Regards, Andrei ________________________________ From: Development <[email protected]> on behalf of Ville Voutilainen <[email protected]> Sent: Tuesday, September 22, 2020 7:01 PM To: Thiago Macieira <[email protected]> Cc: Qt development mailing list <[email protected]> Subject: Re: [Development] QVariant comparison in Qt6 On Tue, 22 Sep 2020 at 17:20, Thiago Macieira <[email protected]> wrote: > And especially if there's no impact to how the user uses the API. > > > 1) > > std::optional<int> compare(); > > > > 2) > > enum class Ordering { Less = -1, Equal = 0, Greater = 1, Unordered = 0xff > > }; > > Ordering compare(); > > > > 3) > > Implement a Qt replacement for std::partial_ordering (could use the std > > stuff if C++ 20 is available) and use that. > > I'd rather stay simple and allow extending for <compare> where more details > are necessary. > > For that, I think #1. If this is an API function that users call, make it (2) but make it a class, not an enum class. You can then later write a conversion operator that converts the result to std::partial_ordering. if this is a private function that no user sees directly, then 1/2 are both fine. The class I mention above basically is a Qt replacement for std::partial_ordering, of course. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
