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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
>>
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
> -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, signa
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
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
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,
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
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
> -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,
> 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
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
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
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 Blas
> -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, signa
ct: 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()
>>>
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
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
>
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
> -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,
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
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
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
> > >>
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?
>
>
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
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.
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).
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?
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
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 alternat
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
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
> -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.
M
> 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 Develop
> -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, signa
On Mon, 17 Feb 2020 at 14:18, Marc Mutz via Development
wrote:
>
> On 2020-02-16 19:32, 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
On 2020-02-16 19:32, 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
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
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
101 - 151 of 151 matches
Mail list logo
