[Development] Disavowing the Lakos Rule for Q_ASSERT

Ville Voutilainen ville.voutilainen at gmail.com
Wed Aug 28 10:07:12 CEST 2024


On Tue, 27 Aug 2024 at 22:23, Thiago Macieira <thiago.macieira at intel.com> wrote:
>
> On Tuesday 27 August 2024 10:29:05 GMT-7 Ville Voutilainen wrote:
> > On Tue, 27 Aug 2024 at 17:15, Thiago Macieira <thiago.macieira at intel.com>
> wrote:
> > > The point is that this putative mistake has no consequences, today. It
> > > remains to be seen whether it will with contracts, when those come. When
> > > contracts come, if those noexcept are a problem, then both libc++ and
> > > libstdc++ will deploy a solution, which should suffice for us too. Until
> > > then, I don't see a reason to deprive ourselves of any potential benefits
> > > that the noexcept might bring.
> >
> > What benefits?
>
> TBH, it's actually very little. But little is not zero.
>
> For the direct use of simple and not-so-simple inline functions, probably
> none. The compiler is good at seeing no exceptions are actually thrown.
>
> It starts to get interesting for code that checks on the noexceptness of the
> content it's calling and use different algorithms. There aren't a lot of those
> outside of container copy, but they do exist.

Just checking.. is that a typo? Do you mean container _move_?

That's by far the most significant case. And if you're using
vector::operator[] there, you're doing something
seriously questionable.


More information about the Development mailing list