On Tue, 27 Aug 2024 at 05:21, Thiago Macieira <thiago.macie...@intel.com> wrote: > > On Monday 26 August 2024 17:18:22 GMT-7 Ville Voutilainen wrote: > > So eventually such libraries > > need to > > be fixed so that they ship configurations and builds where such > > functions can be compiled as non-noexcept with contract checks turned > > on, so that > > throwing violation handlers can be used. With those (useless) > > noexcepts there, we have the library that's supposed to be the most > > generic and the > > most foundational, and it fails to be that, it bakes in a very > > particular failure mode for logic errors. > > Is there a paper proposing the removal of those noexcepts?
Nothing to remove, the spec doesn't make those functions noexcept. > And where does it end? Do any pointer dereferences imply a precondition and > thus not-noexcept? Yes, they do. But for the time being, a dereference of a raw pointer is not a contract violation. And the deference operators for unique_ptr and shared_ptr are noexcept, so that's a violation of the Lakos Rule. There are imperfections in this world. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
