On Monday 26 August 2024 22:16:46 GMT-7 Marc Mutz via Development wrote: > This is an iterator API, and that lhs.item.d == rhs.item.d is a > precondition of the equality operator, so outside of our control. As I > mentioned on Gerrit, we can control the width of the contract we choose > to provide, though: we could make the function have a narrow contract if > we declared iterators with mimatching item.d as partial_ordering::unordered. > > The fundamental problem that iterators into different containers are > incomparable doesn't go away if you slap noexcept on op==. You have a > decision to make: UB or unordered? And _that_ informs whether it's > noexcept or not.
Maybe making those iterators orderable was a mistake. I think I made the CBOR ones orderable because the JSON ones were, but didn't stop to ask why. Anyway, partial ordering is definitely not what is intended. So we simply declare as UB. We can just delete the Q_ASSERT that's a problem. > I agree. This is an internal check about the invariants of the class and > we are in full control over whether they are maintained or broken. This > is not a precondition and the function could be noexcept (if the other > checks pass: no memory allocated and no POSIX cancellation points called). It is so. You removed the memory allocation when you made QUuid::fromRfc4122 take a QByteArrayView but we didn't think to add the noexcept there. > The distinction between the two is why I a weary about the removal of > Q_ASSUME. I guess we could resurrect the distinction with other names > (Q_PRE/Q_POST/Q_INVARIANT)? I wouldn't oppose that, being it as it documents what's a pre/post-condition and what's an internal invariant. It would allow having one set remaining in a build type and not the other too. But it might be confusing to teach our own developers. I don't remember what the issue with Q_ASSUME was any more. As we failed to reach an agreement, there was no point in retaining any knowledge about why. I just point out that we lost the ability to provide hints to the compiler in the process. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
