[Development] Meeting minutes from Qt Release Team meeting 27.08.2024

2024-08-27 Thread Jani Heikkinen via Development
Qt 6.8 status * Beta4 content is frozen, packages are created and testing is ongoing * The target is to release Qt 6.8.0 Beta4 later this week * Qt 6.8.0 String Freeze is in effect now, see https://lists.qt-project.org/pipermail/localization/2024-August/000606.html * Branching

Re: [Development] Disavowing the Lakos Rule for Q_ASSERT

2024-08-27 Thread Thiago Macieira
On Tuesday 27 August 2024 10:29:05 GMT-7 Ville Voutilainen wrote: > On Tue, 27 Aug 2024 at 17:15, Thiago Macieira 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 t

Re: [Development] Disavowing the Lakos Rule for Q_ASSERT

2024-08-27 Thread Ville Voutilainen
On Tue, 27 Aug 2024 at 17:15, Thiago Macieira 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

Re: [Development] Disavowing the Lakos Rule for Q_ASSERT

2024-08-27 Thread Thiago Macieira
On Tuesday 27 August 2024 02:59:34 GMT-7 Giuseppe D'Angelo via Development wrote: > It's not noexcept in the Standard; implementations just chose to make it > so. Libstdc++ chose¹ to have always-terminating precondition > enforcement, i.e. the checks never throw, and so doesn't operator[]. > > We

Re: [Development] Disavowing the Lakos Rule for Q_ASSERT

2024-08-27 Thread Thiago Macieira
On Monday 26 August 2024 22:53:18 GMT-7 Marc Mutz via Development wrote: > If we make the distinction between Q_ASSERT-as-precondition-check and > Q_ASSERT-as-internal-invariant/state-check (with a new macro > name/names), then I can agree to that. Note, however, that the example > that sparked thi

Re: [Development] Disavowing the Lakos Rule for Q_ASSERT

2024-08-27 Thread Giuseppe D'Angelo via Development
On 27/08/2024 04:03, Thiago Macieira wrote: I also urge you to expand on the case of std::vector::operator[]. Are you proposing that it a) become non-noexcept, b) have its UB not defined by the boundary of the precondition, or c) have a precondition that cannot be turned into an exception? It's