Re: [Development] Disavowing the Lakos Rule for Q_ASSERT

2024-09-06 Thread Thiago Macieira
On Friday 6 September 2024 10:55:47 CEST Ville Voutilainen wrote: > > I'm arguing that (c) makes it *worse* because now the exception propagates > > out, causing all sorts of code to be run that we've never, ever tested > > before. > I would be rather surprised if you had tested that code before, >

Re: [Development] QtCS2024 QFuture/QPromise

2024-09-06 Thread Thiago Macieira
On Friday 6 September 2024 16:21:56 CEST Mårten Nordheim via Development wrote: > But do we make it QList _just in case_ there are multiple results > added? From my limited exposure to QFuture/QPromise and in particular the bugs I've had to triage, that is a design flaw. The future/promise does

Re: [Development] Compromise: Modified Lakos Rule (was: Re: Disavowing the Lakos Rule for Q_ASSERT)

2024-09-06 Thread Thiago Macieira
On Friday 6 September 2024 16:15:13 CEST Marc Mutz via Development wrote: > We have Q_DECL_NOTHROW and Q_DECL_NOEXCEPT that we could repurpose for > this, but since we maintain these for backwards compatibility, we > probably don't want do that and change the existing meaning (always > noexcept) un

Re: [Development] Compromise: Modified Lakos Rule (was: Re: Disavowing the Lakos Rule for Q_ASSERT)

2024-09-06 Thread Elvis Stansvik
Den fre 6 sep. 2024 16:16Marc Mutz via Development < development@qt-project.org> skrev: > Hi, > > Over lunch at QtCS, Thiago and I have reached common ground on this. > > Seeding the proposal: > > We continue to follow the Lakos Rule, but if slapping noexcept on a > narrow-contract function demons

[Development] QtCS2024 QFuture/QPromise

2024-09-06 Thread Mårten Nordheim via Development
Hey all, Hope you all had a good time at QtCS so far. Anyway, I was reading through some of the notes. I have looked at QFuture some on my own too... QFuture is quite alright when used for its intended purpose - GUI. Other than that it's too magical. It let's you read results as-they-come, whi

[Development] Compromise: Modified Lakos Rule (was: Re: Disavowing the Lakos Rule for Q_ASSERT)

2024-09-06 Thread Marc Mutz via Development
Hi, Over lunch at QtCS, Thiago and I have reached common ground on this. Seeding the proposal: We continue to follow the Lakos Rule, but if slapping noexcept on a narrow-contract function demonstrably improves "things" (performance, code size?) significantly, then you MAY slap a noexcept on th

Re: [Development] Disavowing the Lakos Rule for Q_ASSERT

2024-09-06 Thread Ville Voutilainen
On Thu, 5 Sept 2024 at 12:24, Thiago Macieira wrote: > > On Thursday 5 September 2024 10:41:51 CEST Ville Voutilainen wrote: > > Well, not necessarily. Consider QVector::operator[]. You can make that > > non-noexcept, slap a precondition > > on it, and use a throwing violation handler. > > > > Eve