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

[Ville Voutilainen]

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.

> 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.

> > Thanks, Christian - that's the first ever plausible explanation for
> > marking a signal emission.
> 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
___
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

[André Pönitz]

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.

See the already mentioned example of debugging in code that follows
the convention of using signals only for inside-out communication:

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.

That's a different situation than, say, just reading code, where an
emit is a flag that assumptions on the calling code might not be
valid anymore.

> [...]
> Thanks, Christian - that's the first ever plausible explanation for
> marking a signal emission.

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.

Andre'

PS: @Marc: Thank you for trying.
___
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

[André Pönitz]

On Fri, Feb 21, 2020 at 02:41:35PM +0200, Ville Voutilainen wrote:
> On Fri, 21 Feb 2020 at 14:30, Mitch Curtis  wrote:
> 
> > > > without any annotation is not what we want. We'd miss vital
> > > > information
> > > and reduce readability.  Can you please explain what that vital
> > > information is?
> > How can you tell if it's a signal being emitted or just a function
> > call without the emit syntax? With the emit syntax before the signal
> > emission, it's immediately obvious that it's a signal. Not all
> > signals follow the *Changed() naming convention, nor should they, so
> > it becomes even less obvious in those cases.
> 
> Why do I need to know that it's a signal being emitted?

The question is not why you need to know that, but why apparently
quite a few people feel that using an empty macro adds value.

My best guess is that different people have different reasons here.

I myself usually prefer shorter code to longer doing the same, so my
natural reaction would be to drop 'emit'. However, I am actually ok with
having it, and that's mainly because it signals the use of a convention
in the code I usually operate on: Signals are use to communicate to an
unknown outside, so one might spend a thought e.g. on how much work this
might trigger, whether threads play a role etc.

> How is that "vital information"?

It's not *vital*, and it's irrelevant to the compiler. It's there for
the human reader.

   int i = 2;

is practically the same as
  
   int fjwqDwerewnrUHBLswd = 2

for an compiler, still some people might prefer one of them.

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

[André Pönitz]

On Fri, Feb 21, 2020 at 08:40:23AM +, Alex Blasche wrote:
> > -Original Message- From: Kai Köhne
> 
> > Another alternative is to actually use C++ attributes for this:
> > 
> >   [[qt::emit]] somethingChanged();
> 
> I think a fallback to 
> 
> somethingChanged() 
> 
> without any annotation is not what we want. We'd miss vital
> information and reduce readability. Having said that I hate Q_EMIT
> even more. It just is ugly as hell. Therefore, I am very glad about
> Kai's suggestion. Personally, I don't think we need an extra namespace
> after all what are the odds to have a clash here  but that's
> details. 

One could have a convention to add an emit_* inline function, i.e.

class Foo : public QObject
{
Q_OBJECT

...

void emit_somethingChanged();

signals:
void somethingChanged()
};


That would require only one character to change on the user side,
instead of 

...
emit somethingChanged()
...

it would be

...
emit_somethingChanged()
...

Also, the use of the emit_-prefixed version would be optional as
before, just using 'somethingChanged()' is possible for those
who prefer that style.

> Last but not least, I don't see why we'd want to disable all other
> keywords when only one of them has a clash.  If the current macro
> enforces this then we should differentiate more. Let's not be too
> hasty when there is no need.

I fully agree.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Thank you for qScopeGuard

[Thiago Macieira]

On Friday, 21 February 2020 06:02:29 PST NIkolai Marchenko wrote:
> it's definitely neat, but it's nothing that you can't do with pure c++
> though. It's just qt's native implementation of score guard pattern. Tbh I
> didn't even know it existed because I use my own scope guarder class.

The reason we added it was because we needed and the Standard Library 
equivalent isn't (wasn't) available in all platforms Qt needed to be compiled 
on.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt5.15 deprecating & Qt6 removing QProcess::setupChildProcess

[Thiago Macieira]

On Friday, 21 February 2020 08:53:33 PST Oswald Buddenhagen wrote:
> On Fri, Feb 21, 2020 at 08:29:54AM -0800, Thiago Macieira wrote:
> >can we deprecate setupChildProcess() in Qt 5.15 and *remove it* in 6.0?
> 
> at least, we should. ;)
> but let's bikeshed the name of the callback setter, which needs to be
> added at the same time -
> setChildProcess{Modifier,Initializer,Setup,...}() ^^

I even thought of making it a signal, like QCoreApplication::aboutToQuit: 
QProcess::childAboutToStart(). That allows for N hooks to be considered, not 
just one, and derived classes like KProcess could insert their own hooks 
independent of their users.

But that is probably a bad idea, as the machinery for emitting signals isn't 
designed to be async-signal-safe. For any receiver in another thread, there's 
also a mutex, which we can't assume we can lock.

If a derived class needs its own child code, it could override the setter and 
wrap calling the user's inside its own.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt5.15 deprecating & Qt6 removing QProcess::setupChildProcess

[Thiago Macieira]

On Friday, 21 February 2020 08:39:57 PST Volker Hilsheimer wrote:
> I’m fine with that, and as communicated by Jani, deprecations can be done
> even with feature freeze in effect, with approval from module maintainer
> (up until Beta1; after that only with Lars’ approval).

Do note the flip side of the coin: adding a new API to replace the overriding.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt5.15 deprecating & Qt6 removing QProcess::setupChildProcess

[Oswald Buddenhagen]

On Fri, Feb 21, 2020 at 08:29:54AM -0800, Thiago Macieira wrote:

can we deprecate setupChildProcess() in Qt 5.15 and *remove it* in 6.0?


at least, we should. ;)
but let's bikeshed the name of the callback setter, which needs to be 
added at the same time - 
setChildProcess{Modifier,Initializer,Setup,...}() ^^

___
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

[Thiago Macieira]

On Friday, 21 February 2020 05:25:13 PST Giuseppe D'Angelo via Development 
wrote:
> * Qt 6.x
> ** Introduce opt-in ways to request lowercase keywords:
> -DQT_USE_KEYWORDS, CONFIG+=keywords, whatever. They do nothing.
> ** Default for user projects is still same as today (use lowercase).
> ** User projects get a deprecation warning unless they specify
> no_keywords and/or keywords. Specifying both keeps keywords.
> 
> * Qt 6.[x..x+3]
> ** Qt turns on no_keywords for itself (all code, examples, docs).
> ** Nothing changes for end-user code.
> 
> * Qt 6.(x+3)
> ** Default for user code becomes no_keywords.
> 
> Am I reading the original proposal correctly? The (x+3) here means that
> there'll be at least one LTS in the middle where behavior won't change
> for end-user applications.

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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt5.15 deprecating & Qt6 removing QProcess::setupChildProcess

[Volker Hilsheimer]

> On 21 Feb 2020, at 17:29, Thiago Macieira  wrote:
> 
> On Tuesday, 18 February 2020 15:44:24 PST Thiago Macieira wrote:
>> $ grep -r 'public QProcess'
>> kcoreaddons/src/lib/io/kprocess.h:class KCOREADDONS_EXPORT KProcess : public
>> QProcess
>> khtml/src/java/kjavaprocess.h:class KJavaProcess : public QProcess //QObject
>> kpty/src/kpty.cpp:class UtemptProcess : public QProcess
>> kwin/utils.h:class KWIN_EXPORT Process : public QProcess
>> 
>> The first two do not override setupChildProcess, the latter two do.
> 
> Do note that the current check means we can't tell that KProcess did not 
> override setupChildProcess. That means any and ALL users of KProcess will 
> need 
> to revert to the older, slower, thread-unsafe, non-pidfd implementation.
> 
> So let me ask again: can we deprecate setupChildProcess() in Qt 5.15 and 
> *remove it* in 6.0?


I’m fine with that, and as communicated by Jani, deprecations can be done even 
with feature freeze in effect, with approval from module maintainer (up until 
Beta1; after that only with Lars’ approval).

And I do assume you will approve :)

Volker

___
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

[Thiago Macieira]

On Friday, 21 February 2020 04:59:02 PST Ville Voutilainen wrote:
> Having a keyword-extension to normal C++ is ugly as sin, to some of
> us. It causes
> fair amounts of "wtf is that?".

That was my reaction when I first saw it, in 1999.

Over 20 years later, I don't bat an eye.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
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

[Thiago Macieira]

On Friday, 21 February 2020 03:21:32 PST Ville Voutilainen wrote:
> Yes, and the name change was discussed but rejected.

Do you know why it was such strong against? Was it, "darn it's too late" or 
was it "we don't care"?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt5.15 deprecating & Qt6 removing QProcess::setupChildProcess

[Thiago Macieira]

On Tuesday, 18 February 2020 15:44:24 PST Thiago Macieira wrote:
> $ grep -r 'public QProcess'
> kcoreaddons/src/lib/io/kprocess.h:class KCOREADDONS_EXPORT KProcess : public
> QProcess
> khtml/src/java/kjavaprocess.h:class KJavaProcess : public QProcess //QObject
> kpty/src/kpty.cpp:class UtemptProcess : public QProcess
> kwin/utils.h:class KWIN_EXPORT Process : public QProcess
> 
> The first two do not override setupChildProcess, the latter two do.

Do note that the current check means we can't tell that KProcess did not 
override setupChildProcess. That means any and ALL users of KProcess will need 
to revert to the older, slower, thread-unsafe, non-pidfd implementation.

So let me ask again: can we deprecate setupChildProcess() in Qt 5.15 and 
*remove it* in 6.0?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Commercial support for Coin and related infrastructure

[Volker Hilsheimer]

> On 20 Feb 2020, at 16:28, Konstantin Tokarev  wrote:
> 
> Hello,
> 
> Are there any options available for subject? I've tried to use official 
> contacts page, but it forces use of corporate email, but my request has 
> nothing to do with any commercial development.
> 
> -- 
> Regards,
> Konstantin


There are no plans to make Coin or related infrastructure available as a 
commercial service.

But curious about the problem you think you would solve better with Coin than 
with any other commercially or freely available alternative.

Cheers,
Volker



___
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

[Shawn Rutledge]

> On 21 Feb 2020, at 14:26, Giuseppe D'Angelo via Development 
>  wrote:
> 
> Il 21/02/20 13:59, Shawn Rutledge ha scritto:
>> (Some people name every slot function starting with the word “slot” to make 
>> clear what it is.)
> 
> So, literally any function they write, since _anything_ can be a slot? Or any 
> function in a QObject subclass? (Not to mention that functions are supposed 
> to describe what they do, not what they react to...)
> 
> Sigh..

Anything that is declared in the slots section of a QObject.  Yeah it’s an 
obsolete convention nowadays, but the company where I worked around 2007-2009 
liked doing it that way.  But while any function can be connected to a signal 
now, not any function can be used as a signal emitter (at least not yet ;-) so 
maybe it makes more sense to have a naming convention for signals rather than 
slots: e.g. signalXChanged.  “Signal” is both a verb and a noun, so in the 
context of calling signalXChanged(), you can read it as “signal that X changed.”

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Thank you for qScopeGuard

[Henry Skoglund]

On 2020-02-21 15:02, NIkolai Marchenko wrote:
it's definitely neat, but it's nothing that you can't do with pure c++ 
though. It's just qt's native implementation of score guard pattern. 
Tbh I didn't even know it existed because I use my own scope guarder 
class.


On Fri, Feb 21, 2020 at 4:33 PM Henry Skoglund > wrote:


Hi, just want to thank whoever worked to implement qScopeGuard (in
5.12), it was a perfect gift from heaven today :-)

I'm writing a LOB app with heavy database munging, and want to
show the
user an hourglass cursor while munging/waiting for MS SQLServer.
However my functions have lots of exits due to bad weather etc. and I
dreaded pasting a restore-mouse-cursor call everywhere. Googled a bit
and now I use this 2-line magic at the top of my functions:
...
 qApp->setOverrideCursor(Qt::WaitCursor);
 auto restoreCursor = qScopeGuard([] {
qApp->restoreOverrideCursor(); });
...

Before I discovered Qt I spent 20 years in MFC purgatory, but now
I've
seen the light!



Agreed, you could roll your own class say in an hour, but it's there, 
*documented* and someone has tested and debugged it for me already. 
That's what "standing on the shoulder of giants" is all about...


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Thank you for qScopeGuard

[NIkolai Marchenko]

it's definitely neat, but it's nothing that you can't do with pure c++
though. It's just qt's native implementation of score guard pattern. Tbh I
didn't even know it existed because I use my own scope guarder class.

On Fri, Feb 21, 2020 at 4:33 PM Henry Skoglund  wrote:

> Hi, just want to thank whoever worked to implement qScopeGuard (in
> 5.12), it was a perfect gift from heaven today :-)
>
> I'm writing a LOB app with heavy database munging, and want to show the
> user an hourglass cursor while munging/waiting for MS SQLServer.
> However my functions have lots of exits due to bad weather etc. and I
> dreaded pasting a restore-mouse-cursor call everywhere. Googled a bit
> and now I use this 2-line magic at the top of my functions:
> ...
>  qApp->setOverrideCursor(Qt::WaitCursor);
>  auto restoreCursor = qScopeGuard([] {
> qApp->restoreOverrideCursor(); });
> ...
>
> Before I discovered Qt I spent 20 years in MFC purgatory, but now I've
> seen the light!
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
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

[Ville Voutilainen]

On Fri, 21 Feb 2020 at 15:44, Christian Kandeler
 wrote:
>
> On Fri, 21 Feb 2020 15:00:53 +0200
> Ville Voutilainen  wrote:
>
> > On Fri, 21 Feb 2020 at 14:58, Sérgio Martins  
> > wrote:
> > > > Why do I need to know that it's a signal being emitted? How is that
> > > > "vital information"? I could just as well
> > > > invoke any other callback, but I find myself not exactly yearning for
> > > > being able to write
> > > > callback somethingHappened();
> > >
> > >
> > > Signals have different semantics than regular functions.
> >
> > In what way?
>
> They typically call back into "upper layers", which is worth considering on 
> the calling side, e.g. due to the danger of inconsistent state getting 
> accessed if you don't emit the signal at the end of a function, to name just 
> one tyical pitfall.
> 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.

A signal emitted yields to a coroutine scheduler that runs arbitrary
callbacks, which in case of direct connections absolutely can affect
the current scope.

Thanks, Christian - that's the first ever plausible explanation for
marking a signal emission.

Getting back to macro vs. function.. I think using a function wrapper
is fine, considering that signals can't
meaningfully return, so the prvalue/xvalue issue doesn't arise. We
could even have qEmit() return void,
to prevent a possible return value from being (ab)used.

Yeah, I'm sure we'll have no trouble finding people who think

qEmit(mah_bucket_callback());

is unacceptably ugly compared to

qEmit mah_bucket_callback();

The big advantage of that ugly version is that it's regular C++
without using macros.

At the risk of riffing on this a tad too far, we could alternatively
consider using an operator on a global dummy
qEmit object, but that runs a risk of getting into precedence games.
___
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

[Christian Kandeler]

On Fri, 21 Feb 2020 15:00:53 +0200
Ville Voutilainen  wrote:

> On Fri, 21 Feb 2020 at 14:58, Sérgio Martins  wrote:
> > > Why do I need to know that it's a signal being emitted? How is that
> > > "vital information"? I could just as well
> > > invoke any other callback, but I find myself not exactly yearning for
> > > being able to write
> > > callback somethingHappened();
> >
> >
> > Signals have different semantics than regular functions.
> 
> In what way?

They typically call back into "upper layers", which is worth considering on the 
calling side, e.g. due to the danger of inconsistent state getting accessed if 
you don't emit the signal at the end of a function, to name just one tyical 
pitfall.
I, for one, definitely want to see whether I am emitting a signal or not.


Christian
___
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

[Giuseppe D'Angelo via Development]

Il 21/02/20 13:59, Shawn Rutledge ha scritto:

(Some people name every slot function starting with the word “slot” to make 
clear what it is.)


So, literally any function they write, since _anything_ can be a slot? 
Or any function in a QObject subclass? (Not to mention that functions 
are supposed to describe what they do, not what they react to...)


Sigh..
--
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

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

[Giuseppe D'Angelo via Development]

Il 20/02/20 14:44, Kai Köhne ha scritto:

As a counter proposal that (I hope) would get broader consensus,  I suggest to 
just do this for 'emit': QTBUG-82379 .


I don't think this is exactly a counter proposal for the plan or the 
scheduling posted by Marc, though. We're now bikeshedding about Q_EMIT 
vs [[qt::emit]] vs. qEmit or anything.



Can we instead discuss about the plan instead? AFAIU it could be 
simplified as:


* Qt 6.x
** Introduce opt-in ways to request lowercase keywords: 
-DQT_USE_KEYWORDS, CONFIG+=keywords, whatever. They do nothing.

** Default for user projects is still same as today (use lowercase).
** User projects get a deprecation warning unless they specify 
no_keywords and/or keywords. Specifying both keeps keywords.


* Qt 6.[x..x+3]
** Qt turns on no_keywords for itself (all code, examples, docs).
** Nothing changes for end-user code.

* Qt 6.(x+3)
** Default for user code becomes no_keywords.

Am I reading the original proposal correctly? The (x+3) here means that 
there'll be at least one LTS in the middle where behavior won't change 
for end-user applications.


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

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

[Konstantin Tokarev]

21.02.2020, 16:18, "Ville Voutilainen" :
> On Fri, 21 Feb 2020 at 14:58, Sérgio Martins  wrote:
>>  > Why do I need to know that it's a signal being emitted? How is that
>>  > "vital information"? I could just as well
>>  > invoke any other callback, but I find myself not exactly yearning for
>>  > being able to write
>>  > callback somethingHappened();
>>
>>  Signals have different semantics than regular functions.
>
> In what way?
>
>>  If I'm reading the body of makePlane() I can ignore the signal
>>  emissions, as they aren't important for how a plane is made, they just
>>  inform whoever is listening.
>
> That doesn't seem to be correct in general. Some signals absolutely
> must be emitted
> for clients to work correctly.
>
>>  And I'd argue that the emitter shouldn't even know who or how many slots
>>  are connected to the signal, might even be zero, it shouldn't matter.
>
> ..and? What does that have to do with whether you do or do you emit?

E.g. it's possible to check if there are any listeners on the signal, and make
a shortcut in code if there aren't any. I've seen such code somewhere in 
qtwidgets

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Thank you for qScopeGuard

[Henry Skoglund]

Hi, just want to thank whoever worked to implement qScopeGuard (in 
5.12), it was a perfect gift from heaven today :-)


I'm writing a LOB app with heavy database munging, and want to show the 
user an hourglass cursor while munging/waiting for MS SQLServer.
However my functions have lots of exits due to bad weather etc. and I 
dreaded pasting a restore-mouse-cursor call everywhere. Googled a bit 
and now I use this 2-line magic at the top of my functions:

...
    qApp->setOverrideCursor(Qt::WaitCursor);
    auto restoreCursor = qScopeGuard([] { 
qApp->restoreOverrideCursor(); });

...

Before I discovered Qt I spent 20 years in MFC purgatory, but now I've 
seen the light!


___
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

[Sérgio Martins via Development]

On 2020-02-21 13:00, Ville Voutilainen wrote:
On Fri, 21 Feb 2020 at 14:58, Sérgio Martins  
wrote:

> Why do I need to know that it's a signal being emitted? How is that
> "vital information"? I could just as well
> invoke any other callback, but I find myself not exactly yearning for
> being able to write
> callback somethingHappened();


Signals have different semantics than regular functions.


In what way?


If I'm reading the body of makePlane() I can ignore the signal
emissions, as they aren't important for how a plane is made, they just
inform whoever is listening.


That doesn't seem to be correct in general. Some signals absolutely
must be emitted
for clients to work correctly.


Signals in the public interface of a self-contained class are not 
important to understand the implementation of said class.


Example:
https://code.woboq.org/qt5/qtbase/src/widgets/widgets/qabstractslider.cpp.html#_ZN15QAbstractSlider17setSliderPositionEi

When reading what QAbstractSlider::setSliderPosition() does, I won't 
check which slots "emit sliderMoved" triggers, but I will

step into triggerAction(SliderMove);


I'm sure you can find counter-examples where the triggered slot does 
something very important for the class that's emitting, I wouldn't call 
it self-contained though.




Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
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

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Shawn Rutledge
> Sent: Friday, 21 February 2020 1:59 PM
> To: development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> 
> > On 21 Feb 2020, at 13:30, Mitch Curtis  wrote:
> > How can you tell if it's a signal being emitted or just a function call 
> > without
> the emit syntax? With the emit syntax before the signal emission, it's
> immediately obvious that it's a signal. Not all signals follow the *Changed()
> naming convention, nor should they, so it becomes even less obvious in
> those cases.
> 
> Invent a naming convention?  Add a feature to Creator that makes it clear,
> like different syntax highlighting or a little symbol next to it?
> 
> (Some people name every slot function starting with the word “slot” to make
> clear what it is.)

Or just use an existing convention, perhaps just under a different name. qEmit 
looks good to me.
 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
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

[Oswald Buddenhagen]

On Fri, Feb 21, 2020 at 12:49:02PM +0100, Julien Cugnière wrote:

For example, a normal function call could end up emiting a signal, and
as such, any function could be as dangerous as a signal.

indeed, the recursivity of the issue utterly destroys the "safety" 
argument.


however, i still like annotating the "emissions" themselves, simply to 
make it obvious that this is only a "notification" and as such not 
expected to directly affect the current scope (yes, i know that signals 
are sometimes abused for implementing callbacks - shame on them). kinda 
the opposite of the safety argument, really.



The other problem with emit, is that it's not required. So its absence
doesn't mean a signal is not being emitted.


that can be enforced with tooling, though.
___
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

[Giuseppe D'Angelo via Development]

Il 21/02/20 09:23, Kai Köhne ha scritto:

Another alternative is to actually use C++ attributes for this:

   [[qt::emit]] somethingChanged();

C++ attributes are required since C++11, and since C++17 the compiler is also 
required to just ignore one's it doesn't know [1]. Because it is part of the 
core language, It is also something every C++ IDE and tool does accept (and 
could even check for) ...


This is a tad verbose, but agreeable IFF we also introduce 
[[qt:::slots]], [[qt::invokable]], [[qt::property()]], and so on -- in 
other words: if we have a _consistent_ set of keywords...


Thanks,
--
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

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

[Ville Voutilainen]

On Fri, 21 Feb 2020 at 15:00, Ville Voutilainen
 wrote:
> > And I'd argue that the emitter shouldn't even know who or how many slots
> > are connected to the signal, might even be zero, it shouldn't matter.
>
> ..and? What does that have to do with whether you do or do you emit?

Mr. Email Client, stop autocorrecting me incorrectly. "..whether you
do or don't use emit".
___
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

[Ville Voutilainen]

On Fri, 21 Feb 2020 at 14:58, Sérgio Martins  wrote:
> > Why do I need to know that it's a signal being emitted? How is that
> > "vital information"? I could just as well
> > invoke any other callback, but I find myself not exactly yearning for
> > being able to write
> > callback somethingHappened();
>
>
> Signals have different semantics than regular functions.

In what way?

> If I'm reading the body of makePlane() I can ignore the signal
> emissions, as they aren't important for how a plane is made, they just
> inform whoever is listening.

That doesn't seem to be correct in general. Some signals absolutely
must be emitted
for clients to work correctly.

> And I'd argue that the emitter shouldn't even know who or how many slots
> are connected to the signal, might even be zero, it shouldn't matter.

..and? What does that have to do with whether you do or do you emit?
___
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

[Giuseppe D'Angelo via Development]

Il 21/02/20 12:49, Julien Cugnière ha scritto:

Isn't that true of any function call though ? Any function could end
up deleting this, or trigerring code in another thread, or anything.
For example, a normal function call could end up emiting a signal, and
as such, any function could be as dangerous as a signal.


Not really: for functions you call explicitly, you know their 
preconditions and postconditions. printf is not going to delete this, 
and malloc is not going to reenter another function of your object while 
you're mutating the state risking to find garbage.


The big difference with signal emission is that they don't generally 
impose anything at all (preconditions, implementation, postconditions) 
on the slots being connected, in the name of loose coupling. As someone 
reasoning on the code emitting the signal, the annotation that control 
is leaving and anything can happen at that point is a positive ε of 
valuable information.



The other problem with emit, is that it's not required. So its absence
doesn't mean a signal is not being emitted.


Sure, but that's why Clazy is angry about emit missing in front of a 
signal call, or if someone puts emit in front of something that is not a 
signal.


--
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

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

[Mitch Curtis]

> -Original Message-
> From: Eike Ziller 
> Sent: Friday, 21 February 2020 1:55 PM
> To: Mitch Curtis 
> Cc: Ville Voutilainen ; Alex Blasche
> ; development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> 
> 
> > On 21. Feb 2020, at 13:30, Mitch Curtis  wrote:
> > How can you tell if it's a signal being emitted or just a function call 
> > without
> the emit syntax? With the emit syntax before the signal emission, it's
> immediately obvious that it's a signal.
> 
> It isn’t because you can put “emit” anywhere in your code because it has no
> semantics for the compiler.

There are lots of nonsensical things you can do with the language. I'm thinking 
in the context of people who are trying to make their code easy to read, not 
prove a point.

> It’s not beter than any code comment that you could also put there, like
> 
> /*emit*/ something();
> 
> or
> 
> something(); // emit
> 
> > Not all signals follow the *Changed() naming convention, nor should they,
> so it becomes even less obvious in those cases.
> >
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> https://lists.qt-project.org/listinfo/development
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> --
> Eike Ziller
> Principal Software Engineer
> 
> The Qt Company GmbH
> Erich-Thilo-Straße 10
> D-12489 Berlin
> eike.zil...@qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B

___
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

[Shawn Rutledge]

> On 21 Feb 2020, at 13:30, Mitch Curtis  wrote:
> How can you tell if it's a signal being emitted or just a function call 
> without the emit syntax? With the emit syntax before the signal emission, 
> it's immediately obvious that it's a signal. Not all signals follow the 
> *Changed() naming convention, nor should they, so it becomes even less 
> obvious in those cases.

Invent a naming convention?  Add a feature to Creator that makes it clear, like 
different syntax highlighting or a little symbol next to it?

(Some people name every slot function starting with the word “slot” to make 
clear what it is.)

___
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

[Ville Voutilainen]

On Fri, 21 Feb 2020 at 14:57, Mitch Curtis  wrote:
> > It’s not beter than any code comment that you could also put there, like
> >
> > /*emit*/ something();
> >
> > or
> >
> > something(); // emit
>
> I disagree; I think those are ugly.

Having a keyword-extension to normal C++ is ugly as sin, to some of
us. It causes
fair amounts of "wtf is that?".
___
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

[Sérgio Martins via Development]

On 2020-02-21 12:41, Ville Voutilainen wrote:

On Fri, 21 Feb 2020 at 14:30, Mitch Curtis  wrote:


> > without any annotation is not what we want. We'd miss vital information
> and reduce readability.
> Can you please explain what that vital information is?
How can you tell if it's a signal being emitted or just a function 
call without the emit syntax? With the emit syntax before the signal 
emission, it's immediately obvious that it's a signal. Not all signals 
follow the *Changed() naming convention, nor should they, so it 
becomes even less obvious in those cases.


Why do I need to know that it's a signal being emitted? How is that
"vital information"? I could just as well
invoke any other callback, but I find myself not exactly yearning for
being able to write
callback somethingHappened();



Signals have different semantics than regular functions.

If I'm reading the body of makePlane() I can ignore the signal 
emissions, as they aren't important for how a plane is made, they just 
inform whoever is listening.


And I'd argue that the emitter shouldn't even know who or how many slots 
are connected to the signal, might even be zero, it shouldn't matter.


If you really need to execute a piece of code, call a normal function, 
don't emit a signal.






Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
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

[Mitch Curtis]

> -Original Message-
> From: Eike Ziller 
> Sent: Friday, 21 February 2020 1:55 PM
> To: Mitch Curtis 
> Cc: Ville Voutilainen ; Alex Blasche
> ; development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> 
> 
> > On 21. Feb 2020, at 13:30, Mitch Curtis  wrote:
> >
> >> -Original Message-
> >> From: Development  On Behalf
> Of
> >> Ville Voutilainen
> >> Sent: Friday, 21 February 2020 12:16 PM
> >> To: Alex Blasche 
> >> Cc: development@qt-project.org
> >> Subject: Re: [Development] A modest proposal: disable lower-case
> >> keywords (emit, foreach, forever, signals, slots) by default
> >>
> >> On Fri, 21 Feb 2020 at 10:42, Alex Blasche 
> wrote:
> >>> I think a fallback to
> >>>
> >>> somethingChanged()
> >>>
> >>> without any annotation is not what we want. We'd miss vital
> >>> information
> >> and reduce readability.
> >>
> >> Can you please explain what that vital information is?
> >
> > How can you tell if it's a signal being emitted or just a function call 
> > without
> the emit syntax? With the emit syntax before the signal emission, it's
> immediately obvious that it's a signal.
> 
> It isn’t because you can put “emit” anywhere in your code because it has no
> semantics for the compiler.

I never said it had any semantic purpose, I'm purely arguing that it has 
implications for readability.

> It’s not beter than any code comment that you could also put there, like
> 
> /*emit*/ something();
> 
> or
> 
> something(); // emit

I disagree; I think those are ugly.

> > Not all signals follow the *Changed() naming convention, nor should they,
> so it becomes even less obvious in those cases.
> >
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> https://lists.qt-project.org/listinfo/development
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> --
> Eike Ziller
> Principal Software Engineer
> 
> The Qt Company GmbH
> Erich-Thilo-Straße 10
> D-12489 Berlin
> eike.zil...@qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B

___
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

[Mitch Curtis]

> -Original Message-
> From: Ville Voutilainen 
> Sent: Friday, 21 February 2020 1:42 PM
> To: Mitch Curtis 
> Cc: Alex Blasche ; development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> On Fri, 21 Feb 2020 at 14:30, Mitch Curtis  wrote:
> 
> > > > without any annotation is not what we want. We'd miss vital
> > > > information
> > > and reduce readability.
> > > Can you please explain what that vital information is?
> > How can you tell if it's a signal being emitted or just a function call 
> > without
> the emit syntax? With the emit syntax before the signal emission, it's
> immediately obvious that it's a signal. Not all signals follow the *Changed()
> naming convention, nor should they, so it becomes even less obvious in
> those cases.
> 
> Why do I need to know that it's a signal being emitted? How is that "vital
> information"? I could just as well invoke any other callback, but I find 
> myself
> not exactly yearning for being able to write callback somethingHappened();

I can't answer why you need to know, but for me personally, it's just one less 
small thing to think about. I'm not going to try to step into it while 
debugging, for example, and end up in some tasty moc guts. It's like const on 
local variables; a lot of people leave it out but I like having it because it's 
one less thing to consider when I'm already tired and have been thinking all 
day. :)

Having the emit syntax costs the people who don't want to use it nothing, and I 
know which code I'd rather have to maintain.
___
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

[Eike Ziller]

> On 21. Feb 2020, at 13:30, Mitch Curtis  wrote:
> 
>> -Original Message-
>> From: Development  On Behalf Of
>> Ville Voutilainen
>> Sent: Friday, 21 February 2020 12:16 PM
>> To: Alex Blasche 
>> Cc: development@qt-project.org
>> Subject: Re: [Development] A modest proposal: disable lower-case
>> keywords (emit, foreach, forever, signals, slots) by default
>> 
>> On Fri, 21 Feb 2020 at 10:42, Alex Blasche  wrote:
>>> I think a fallback to
>>> 
>>> somethingChanged()
>>> 
>>> without any annotation is not what we want. We'd miss vital information
>> and reduce readability.
>> 
>> Can you please explain what that vital information is?
> 
> How can you tell if it's a signal being emitted or just a function call 
> without the emit syntax? With the emit syntax before the signal emission, 
> it's immediately obvious that it's a signal.

It isn’t because you can put “emit” anywhere in your code because it has no 
semantics for the compiler.
It’s not beter than any code comment that you could also put there, like

/*emit*/ something();

or 

something(); // emit

> Not all signals follow the *Changed() naming convention, nor should they, so 
> it becomes even less obvious in those cases.
> 
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
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

[Ville Voutilainen]

On Fri, 21 Feb 2020 at 14:21, Ville Voutilainen
 wrote:
>
> On Fri, 21 Feb 2020 at 14:00, Allan Sandfeld Jensen  wrote:
> > Hmm.. Or perhaps:
> >
> > #define qEmit(x) x
> > or
> > #define qEmit(x) do { x; } while (false)
> > to handle the syntactic edge cases.
>
> Well, if we're re-entertaining a function-like wrapper, we could just
> as well avoid
> getting back to the not-so-wonderful world of macros, and do
> template  T&& qEmit(T&& t) {return std::forward(t);}

..but this doesn't really work, because it turns prvalues into
xvalues, and thwarts lifetime extension of reference
to prvalues, so scratch that idea.
___
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

[Ville Voutilainen]

On Fri, 21 Feb 2020 at 14:30, Mitch Curtis  wrote:

> > > without any annotation is not what we want. We'd miss vital information
> > and reduce readability.
> > Can you please explain what that vital information is?
> How can you tell if it's a signal being emitted or just a function call 
> without the emit syntax? With the emit syntax before the signal emission, 
> it's immediately obvious that it's a signal. Not all signals follow the 
> *Changed() naming convention, nor should they, so it becomes even less 
> obvious in those cases.

Why do I need to know that it's a signal being emitted? How is that
"vital information"? I could just as well
invoke any other callback, but I find myself not exactly yearning for
being able to write
callback somethingHappened();
___
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

[Oswald Buddenhagen]

On Fri, Feb 21, 2020 at 08:23:51AM +, Kai Koehne wrote:

Another alternative is to actually use C++ attributes for this:

 [[qt::emit]] somethingChanged();

that's a terrible idea, because it's visually noisy (and correspondingly 
bothersome to type).


if anything, i'd go for

#define qEmit
___
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

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Ville Voutilainen
> Sent: Friday, 21 February 2020 12:16 PM
> To: Alex Blasche 
> Cc: development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, signals, slots) by default
> 
> On Fri, 21 Feb 2020 at 10:42, Alex Blasche  wrote:
> > I think a fallback to
> >
> > somethingChanged()
> >
> > without any annotation is not what we want. We'd miss vital information
> and reduce readability.
> 
> Can you please explain what that vital information is?

How can you tell if it's a signal being emitted or just a function call without 
the emit syntax? With the emit syntax before the signal emission, it's 
immediately obvious that it's a signal. Not all signals follow the *Changed() 
naming convention, nor should they, so it becomes even less obvious in those 
cases.
 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
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

[Ville Voutilainen]

On Fri, 21 Feb 2020 at 13:52, Julien Cugnière  wrote:
>
> Le ven. 21 févr. 2020 à 12:29, Giuseppe D'Angelo via Development
>  a écrit :
> >
> > Il 21/02/20 12:15, Ville Voutilainen ha scritto:
> > >> without any annotation is not what we want. We'd miss vital information 
> > >> and reduce readability.
> > > Can you please explain what that vital information is?
> >
> > That control is leaving the "local" function, and *anything* can happen
> > at that point. Including fun stuff, like finding "this" to be deleted
> > (pgrep for QPointer.*this in QWidget code). It's an important annotation
> > for a developer IMNSHO.
>
> Isn't that true of any function call though ? Any function could end
> up deleting this, or trigerring code in another thread, or anything.
> For example, a normal function call could end up emiting a signal, and
> as such, any function could be as dangerous as a signal.

Indeed. I'm still waiting for an explanation for the need for emit. I
am trying as hard as I can
to spot such a need, and failing. The apparent need is riding on a
hypothesis that signals
are special, but they aren't. They are just like all other functions,
albeit generated functions,
but in that sense no different from other functions that you didn't write.
___
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

[Ville Voutilainen]

On Fri, 21 Feb 2020 at 14:00, Allan Sandfeld Jensen  wrote:
> Hmm.. Or perhaps:
>
> #define qEmit(x) x
> or
> #define qEmit(x) do { x; } while (false)
> to handle the syntactic edge cases.

Well, if we're re-entertaining a function-like wrapper, we could just
as well avoid
getting back to the not-so-wonderful world of macros, and do
template  T&& qEmit(T&& t) {return std::forward(t);}
___
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

[Allan Sandfeld Jensen]

On Friday, 21 February 2020 12:44:56 CET Allan Sandfeld Jensen wrote:
> On Friday, 21 February 2020 12:28:29 CET Giuseppe D'Angelo via Development
> 
> wrote:
> > Il 21/02/20 12:15, Ville Voutilainen ha scritto:
> > >> without any annotation is not what we want. We'd miss vital information
> > >> and reduce readability.>
> > > 
> > > Can you please explain what that vital information is?
> > 
> > That control is leaving the "local" function, and *anything* can happen
> > at that point. Including fun stuff, like finding "this" to be deleted
> > (pgrep for QPointer.*this in QWidget code). It's an important annotation
> > for a developer IMNSHO.
> 
> That information could be preserved if we named the signal functions
> emitSignalName instead, though that would look worse at the binding.
> 
Hmm.. Or perhaps:

#define qEmit(x) x
or
#define qEmit(x) do { x; } while (false) 
to handle the syntactic edge cases.

Would also make it possible to define an alternative pattern we use a lot
in QtWebEngine, a qAsyncEmit() that would emit over a 0 time singleShot
timer (basically handle all listeners after returning to the event loop)

'Allan






___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: more Jira states to track stages of the work on an issue

[Maurice Kalinowski]

Hi,

Just adding in another vote for introducing a “In Review/Integration” state.
As a disclaimer, I am working in the same team as Eddy.

The reason I see it beneficial is to have better visibility on the progress of 
working on a certain task. Eddy already made it clear that while something is 
“in review” or in the process of getting integrated or “waiting for other 
changes to merge”, there is no active work on this task happening. Defining 
that as “In Progress” is misleading.

Some people indicated that it feels like pressing a process into the workflow. 
I would like to highlight that this is absolutely not the case. Neither is this 
a PM decision or anything alike. It’s simply that recently we figured that with 
running sprints, the time spend on coding itself is only a fraction of time 
until a task gets resolved. We have had multiple (maybe even the majority) 
incidents of tasks running/sliding through multiple sprints, as we were not 
able to merge.
To repeat, the idea is to improve on the visibility of a state of a task.


Some might now say “Well, if integration (or CI) is the problem, then fix this 
rather than introduce another state”.
That’s a valid point. But only if there are evident indicators. Personally, I 
prefer to have metrics proving a point, and that might be one mean to achieve 
this. Heck, we might even get to a point that this is not needed anymore, as 
everything goes super smooth (ie 5 minutes from issue raised to integration 
done reference before). But first, I do not see this happening within the 
foreseeable future. Secondly, are we really that gridlocked to not change 
anything at all because it might be revisited at some point?


What I also miss in this thread is a suggestion on how this could be handled 
differently?
One idea which came up in discussions is to declare an issue as “blocked” while 
it is waiting for integration. But imho that does not make any sense either. 
First, because blocked is in the “Open” State, which indicates that no one is 
currently looking at it at all and the task is free to grab by anyone. 
Furthermore, “blocked” usually means other external factors to justify this 
state.

I’d also like to share the link to Atlassian’s workflow proposal on how to 
create an agile workflow in JIRA.
https://www.atlassian.com/agile/project-management/workflow

Note that this also includes two separate “active” states.

BR,
Maurice




> -Original Message-
> From: Development  On Behalf Of
> Edward Welbourne
> Sent: Thursday, February 20, 2020 2:37 PM
> To: Tobias Hunger 
> Cc: development@qt-project.org
> Subject: Re: [Development] Proposal: more Jira states to track stages of the
> work on an issue
> 
> On Mon, 2020-02-17 at 09:13 +, Edward Welbourne wrote:
> >> We currently have an "In Progress" state.  In practice when I work on
> >> an issue, I initially do the work, then put that up for review; the
> >> review phase takes up fragments of my time for a while, unlike the
> >> main work phase, which is closer to full-time.  I have more control
> >> over (and a better ability to estimate) how long the actual work
> >> takes, while review (and subsequent integration) depends on factors
> >> outside my control, that are harder to estimate.
> 
> Tobias Hunger (20 February 2020 10:00) replied:
> > If the review process does not ever result in a significant amount of
> > work (== no patch is ever rejected or significantly changed do to a
> > review process), then we should reevaluate the review process. If this
> > is indeed the case, then Gerrit has degenerated into a place to
> > discuss formatting -- something we could have clang-format take care
> > of automatically!
> >
> > If our review process is more than a formality then it might result in
> > a significant amount of work -- the patch can be rejected or you might
> > end up redoing significant parts of the code. In that case I do not
> > see how you can consider your original task done before the review is
> complete.
> >
> > In both cases, IMHO having a separate state in JIRA provides very
> > limited benefit.
> 
> I'm not suggesting or claiming either of those things, nor are they any part 
> of
> the case I'm making for having a separate state in Jira.
> 
> I'm better able to estimate how long I'll take to do the work before review
> than to estimate the time it'll take for that work to get through review; but,
> usually, the amount of *my* time that'll be taken up by the work during
> review is small compared to the amount of work I do before sending it for
> review.  So, when it comes to planning my work and communicating what I'm
> doing and when I expect it to be done, there is a vast difference between
> the work I do before review and the work I do in review.
> 
> * Before review: more or less full-time work, taking relatively
>   predictable large amounts of my time over a relatively predictable
>   calendar duration.
> 
> * In review: sporadic work, usually cumulatively smaller 

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

[Julien Cugnière]

Le ven. 21 févr. 2020 à 12:29, Giuseppe D'Angelo via Development
 a écrit :
>
> Il 21/02/20 12:15, Ville Voutilainen ha scritto:
> >> without any annotation is not what we want. We'd miss vital information 
> >> and reduce readability.
> > Can you please explain what that vital information is?
>
> That control is leaving the "local" function, and *anything* can happen
> at that point. Including fun stuff, like finding "this" to be deleted
> (pgrep for QPointer.*this in QWidget code). It's an important annotation
> for a developer IMNSHO.

Isn't that true of any function call though ? Any function could end
up deleting this, or trigerring code in another thread, or anything.
For example, a normal function call could end up emiting a signal, and
as such, any function could be as dangerous as a signal.

The other problem with emit, is that it's not required. So its absence
doesn't mean a signal is not being emitted.
___
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

[Allan Sandfeld Jensen]

On Friday, 21 February 2020 12:28:29 CET Giuseppe D'Angelo via Development 
wrote:
> Il 21/02/20 12:15, Ville Voutilainen ha scritto:
> >> without any annotation is not what we want. We'd miss vital information
> >> and reduce readability.> 
> > Can you please explain what that vital information is?
> 
> That control is leaving the "local" function, and *anything* can happen
> at that point. Including fun stuff, like finding "this" to be deleted
> (pgrep for QPointer.*this in QWidget code). It's an important annotation
> for a developer IMNSHO.
> 
That information could be preserved if we named the signal functions 
emitSignalName instead, though that would look worse at the binding.

'Allan



___
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

[Giuseppe D'Angelo via Development]

Il 21/02/20 12:15, Ville Voutilainen ha scritto:

without any annotation is not what we want. We'd miss vital information and 
reduce readability.

Can you please explain what that vital information is?


That control is leaving the "local" function, and *anything* can happen 
at that point. Including fun stuff, like finding "this" to be deleted 
(pgrep for QPointer.*this in QWidget code). It's an important annotation 
for a developer IMNSHO.


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

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

[Ville Voutilainen]

On Fri, 21 Feb 2020 at 10:47, Allan Sandfeld Jensen  wrote:
>
> On Sunday, 16 February 2020 19:32:02 CET Thiago Macieira wrote:
> > On Saturday, 15 February 2020 06:23:52 PST Marc Mutz via Development wrote:
> > > C++20 will contain new classes with emit() member functions
> > > (wg21.link/P0053). While that will only pose problems for users that
> > > include the new  header after (almost) any Qt header, this
> > > should serve as a second shot across the bows (after namespace
> > > boost::signals) that we should change something.
> >
> > Orthogonal to your request: can we ask C++20 to change the name of this
> > function? We've been #define'ing emit for nearly 30 years.
>
> Didn't C++20 just finalize, in any case?

Yes, and the name change was discussed but rejected.
___
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

[Ville Voutilainen]

On Fri, 21 Feb 2020 at 10:42, Alex Blasche  wrote:
> I think a fallback to
>
> somethingChanged()
>
> without any annotation is not what we want. We'd miss vital information and 
> reduce readability.

Can you please explain what that vital information is?
___
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

[Konstantin Shegunov]

On Fri, Feb 21, 2020 at 10:25 AM Kai Köhne  wrote:

> Hi,
>
> Another alternative is to actually use C++ attributes for this:
>
>   [[qt::emit]] somethingChanged();
>

Nice idea, +1.
___
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

[Daniel Engelke]

Hey, 

That's a great idea.


Dan


From:   Vad Rulezz  
 To:
 Sent:   2/21/2020 9:52 AM 
 Subject:   Re: [Development] A modest proposal: disable lower-case keywords 
(emit, foreach, forever, signals, slots) by default 

Hello,

On 2/21/20 11:23 AM, Kai Köhne wrote:
> Another alternative is to actually use C++ attributes for this:
> 
>    [[qt::emit]] somethingChanged();

+1 Good idea.


Vad
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
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

[Vad Rulezz]

Hello,

On 2/21/20 11:23 AM, Kai Köhne wrote:

Another alternative is to actually use C++ attributes for this:

   [[qt::emit]] somethingChanged();


+1 Good idea.


Vad
___
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

[Allan Sandfeld Jensen]

On Sunday, 16 February 2020 19:32:02 CET Thiago Macieira wrote:
> On Saturday, 15 February 2020 06:23:52 PST Marc Mutz via Development wrote:
> > C++20 will contain new classes with emit() member functions
> > (wg21.link/P0053). While that will only pose problems for users that
> > include the new  header after (almost) any Qt header, this
> > should serve as a second shot across the bows (after namespace
> > boost::signals) that we should change something.
> 
> Orthogonal to your request: can we ask C++20 to change the name of this
> function? We've been #define'ing emit for nearly 30 years.

Didn't C++20 just finalize, in any case?

'Allan




___
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

[Alex Blasche]

> -Original Message-
> From: Kai Köhne

> Another alternative is to actually use C++ attributes for this:
> 
>   [[qt::emit]] somethingChanged();

I think a fallback to 

somethingChanged() 

without any annotation is not what we want. We'd miss vital information and 
reduce readability. Having said that I hate Q_EMIT even more. It just is ugly 
as hell. Therefore, I am very glad about Kai's suggestion. Personally, I don't 
think we need an extra namespace after all what are the odds to have a clash 
here  but that's details. 

Last but not least, I don't see why we'd want to disable all other keywords 
when only one of them has a clash. If the current macro enforces this then we 
should differentiate more. Let's not be too hasty when there is no need.

--
Alex 

___
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

[Kai Köhne]

Hi,

Another alternative is to actually use C++ attributes for this:

  [[qt::emit]] somethingChanged();

C++ attributes are required since C++11, and since C++17 the compiler is also 
required to just ignore one's it doesn't know [1]. Because it is part of the 
core language, It is also something every C++ IDE and tool does accept (and 
could even check for) ...

Kai

[1]: In C++11, gcc and clang seem to still warn. However, there are options to 
disable this.

> -Original Message-
> From: Development  On Behalf Of Kai
> Köhne
> Sent: Thursday, February 20, 2020 2:44 PM
> To: Marc Mutz ; development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case keywords
> (emit, foreach, forever, signals, slots) by default
> 
> > -Original Message-
> > From: Development  On Behalf Of
> > Marc Mutz via Development
> > Sent: Saturday, February 15, 2020 3:24 PM
> > To: development@qt-project.org
> > Subject: [Development] A modest proposal: disable lower-case keywords
> > (emit, foreach, forever, signals, slots) by default
> >
> > Hi,
> >
> > C++20 will contain new classes with emit() member functions
> > (wg21.link/P0053). While that will only pose problems for users that
> > include the new  header after (almost) any Qt header,
> > this should serve as a second shot across the bows (after namespace
> > boost::signals) that we should change something.
> >
> > To that effect, I'd like to propose that we switch the default for
> > QT_NO_KEYWORDS around.
> 
> As a counter proposal that (I hope) would get broader consensus,  I suggest to
> just do this for 'emit': QTBUG-82379 .
> 
> This keyword always seemed a bit odd to me anyway, because it has no
> semantics that's ensured by the compiler. I understand the ratio behind it, 
> and
> there's obviously tons of code that uses it. But if I have the choice between
> 
>   Q_EMIT somethingChanged();
> 
> and just
> 
>  somethingChanged();
> 
> I personally prefer the second.
> 
> My 2 cents,
> 
> Kai
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development