[Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[André Pönitz]

On Fri, Feb 21, 2020 at 11:03:19PM +0200, Ville Voutilainen wrote:
> On Fri, 21 Feb 2020 at 22:11, André Pönitz <apoenitz at t-online.de> 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'