Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Sat, 22 Feb 2020 at 13:07, André Pönitz wrote: > > Buy a debugger that can skip code that you didn't write. > > The point was that in a such a situation I, as user, would not even > try to step in when the call is marked with 'emit'. This 'emit' in > a line *is* valuable markup, that saves me time. > > That's unrelated to what the debugger would or could do if I did step in, > I just don't need to follow that path. > > [And apart from that: There's no need to *buy* such debugger, e.g. gdb's > 'skip' actually works] It occurs to me that, in case Creator doesn't do that already, we could make its debugger UI to automatically tell the underlying debugger to skip moc-generated code, as a default. > > The committee shot down the proposal because > > 1) there are work-arounds to the problem, and we already use those > > work-arounds for similar > > issues with boost::signal > > 2) trying to avoid clashes with lowercase non-function-like macros is > > rather difficult > > 3) the scope of the problem is narrow > > 4) no existing code is broken > > Is that documented, perhaps with a bit more detail, somewhere? Not that I know of - the LWG issue hasn't been updated yet. Is there some particular detail that you're missing? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Fri, Feb 21, 2020 at 11:03:19PM +0200, Ville Voutilainen wrote: > On Fri, 21 Feb 2020 at 22:11, André Pönitz wrote: > > > > On Fri, Feb 21, 2020 at 04:02:04PM +0200, Ville Voutilainen wrote: > > > > I, for one, definitely want to see whether I am emitting a signal or > > > > not. > > > > > > Right; the claims that you can ignore signal emits when looking at a > > > piece of code or expect that they > > > don't affect the current scope are exactly backwards. > > > > Christian is right and your conclusion is wrong. > > My conclusion is fine. Your unsubstantiated claims don't make it wrong. > > > See the already mentioned example of debugging in code that follows > > the convention of using signals only for inside-out communication: > > Buy a debugger that can skip code that you didn't write. The point was that in a such a situation I, as user, would not even try to step in when the call is marked with 'emit'. This 'emit' in a line *is* valuable markup, that saves me time. That's unrelated to what the debugger would or could do if I did step in, I just don't need to follow that path. [And apart from that: There's no need to *buy* such debugger, e.g. gdb's 'skip' actually works] > > Emitting the signal may cause all kind of activity on the outside, > > but in first approximation one can assume it doesn't change state in > > the current object. So when drilling down in this situation > > "ignoring" emit is indeed natural. > > Seems quite unnatural to me, considering that signal emissions > reasonably often tend to result in further calls being made to the object. I stated as pre-condition that this is about "code that follows the convention of using signals only for inside-out communication". > > This sounds a bit like the committee shot down the proposal to > > not use 'emit' without even bothering to think about reasons why > > there are users of this "nonsense", let alone tried to ask them. > > The committee shot down the proposal because > 1) there are work-arounds to the problem, and we already use those > work-arounds for similar > issues with boost::signal > 2) trying to avoid clashes with lowercase non-function-like macros is > rather difficult > 3) the scope of the problem is narrow > 4) no existing code is broken Is that documented, perhaps with a bit more detail, somewhere? Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
Il 21/02/20 17:42, Thiago Macieira ha scritto: The first step would be for both qmake and cmake projects to warn if the project doesn't declare keywords or no_keywords. Allow that to stay for 2 or 3 years so projects do update to declare their choices. This can start right now, in 5.15. At some point after that, change the default. Like, for example, in Qt 7. A data point I'd like to have is how many "real world" projects are enforcing no_keywords, at the moment? Are we going to make life more awkward for everyone, with a marginal gain (stop polluting the preprocessor with lowercase macros), or _de facto_ any big project already disables the macros anyhow? My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
