On 15.2.2020 16.23, Marc Mutz via Development wrote:
> 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
From: Development on behalf of Ville
Voutilainen
On Wed, 26 Feb 2020 at 18:45, Benjamin TERRIER wrote:
>> I would like the idea of using attributes for this. However, compilers are
>> allowed to warn for unknown attributes, which is useful to detect
On Wed, 26 Feb 2020 at 18:45, Benjamin TERRIER wrote:
> I would like the idea of using attributes for this. However, compilers are
> allowed to warn for unknown attributes, which is useful to detect typos.
> This means that we would get a warning for each usage of [[qt::emit]]. So
> unless
26.02.2020, 19:28, "Alex Blasche" :
>> Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø:
>> > We don’t need one rule to rule them all either. Many signals are named
>> fooChanged(), and can perfectly well stand on their own, without
>> annotations.
>> Corner cases like "emit pressed();” can be
On Fri, 21 Feb 2020 at 09:24, Kai Köhne wrote:
> 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].
> -Original Message-
> From: Lars Knoll
> >> -Original Message-
> >> From: Lars Knoll
> I’m not trying to make this only about emit. But it’s the concrete
> problem we’re facing now, and emit is IMO the one keyword where we
> simply don’t need a replacement
> -Original Message-
> From: Development On Behalf Of
> Simon Hausmann
Please don't generalise where there is no general or even majority count (see
below).
> Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø:
> > We don’t need one rule to rule them all either. Many signals are named
>
On 2/15/20 3:23 PM, Marc Mutz via Development wrote:
> Hi,
>
> C++20 will contain new classes with emit() member functions
> (wg21.link/P0053).
>
Hello,
I know this discussion is about C++,
but I just wanted to mention that Signals
in Python are objects, and we rely on the emit method
to
Oliver Wolff (26 February 2020 15:10) wrote
[snip]
> it serves a purpose to me. "Look here a signal is emitted, so that other
> parts who are interested in this information might react". For me that's
> important information when reading code (be it while coding or in code
> reviews).
Indeed. As
Hi,
On 21/02/2020 13:57, Mitch Curtis wrote:
>> -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
26.02.2020, 16:34, "Simon Hausmann" :
> Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø:
>>> We’re neither enforcing the use of ‘emit’ currently. And I honestly find
>>> most of the alternatives to be worse than no annotation at all.
>> I agree.
>>
>> As others have argued, a signal is not
Am 26.02.20 um 13:42 schrieb Tor Arne Vestbø:
>> We’re neither enforcing the use of ‘emit’ currently. And I honestly find
>> most of the alternatives to be worse than no annotation at all.
> I agree.
>
> As others have argued, a signal is not special, in the sense that any
> function can do
On Wed, 26 Feb 2020 at 14:44, Tor Arne Vestbø wrote:
> > We’re neither enforcing the use of ‘emit’ currently. And I honestly find
> > most of the alternatives to be worse than no annotation at all.
>
> I agree.
>
> As others have argued, a signal is not special, in the sense that any
>
>>Were neither enforcing the use of emit currently. And I honestly
>> find most of the alternatives to be worse than no annotation at all.
As an illustration, for many years, I have the naming convention to
start all my signals with... "signal"
eg. signalChange();
This notation is so
> On 26 Feb 2020, at 13:30, Lars Knoll wrote:
>
>
>
>> On 26 Feb 2020, at 10:38, Alex Blasche wrote:
>>
>>
>>
>>> -Original Message-
>>> From: Lars Knoll
> I’m not trying to make this only about emit. But it’s the concrete
> problem we’re facing now, and emit is IMO the
> On 26 Feb 2020, at 10:38, Alex Blasche wrote:
>
>
>
>> -Original Message-
>> From: Lars Knoll
I’m not trying to make this only about emit. But it’s the concrete
problem we’re facing now, and emit is IMO the one keyword where we
simply don’t need a replacement
>From: Volker Hilsheimer
>
> The priority field changes it’s meaning during the lifetime of the bug report:
>
> * in the beginning, it tells us how important it is for the reporter of the
> bug. This is useful.
This is news to me; I've not once heard of it being used this way. I also
> On 26 Feb 2020, at 11:45, Mitch Curtis wrote:
>
>>
>> From: Development on behalf of Lorn
>> Potter
>> Sent: Wednesday, 26 February 2020 11:15 AM
>> To: development@qt-project.org
>> Subject: Re: [Development] Priority field in Jira
>>
>> On 25/2/20
Actually, priority field is not that useful. Anything except P0 and P1 can hang
indefinitely in unsolved state, and I agree that assigning P0 or P1 should be
restricted.
--
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
>
>From: Development on behalf of Lorn
>Potter
>Sent: Wednesday, 26 February 2020 11:15 AM
>To: development@qt-project.org
>Subject: Re: [Development] Priority field in Jira
>
>On 25/2/20 8:11 PM, Joerg Bornemann wrote:
>> On 2/25/20 10:31, Edward
On 25/2/20 8:11 PM, Joerg Bornemann wrote:
On 2/25/20 10:31, Edward Welbourne wrote:
How about: because we can always over-ride them if we really disagree;
and their prioritising of the bug is an opening for discussion of why
it's so important to them - which, after all, we might have
> -Original Message-
> From: Lars Knoll
> >> I’m not trying to make this only about emit. But it’s the concrete
> >> problem we’re facing now, and emit is IMO the one keyword where we
> >> simply don’t need a replacement because it has no real semantic meaning in
> C++.
> >
> > I don't
> I don't think semantics matter here. It is all about annotation and
readability. With the same arguments we design APIs. While Kai's survey is
inconclusive about the actual solution, it is conclusive in one aspect.
There is a clear majority to have sth in place for annotation/readability
> On 26 Feb 2020, at 09:16, Alex Blasche wrote:
>
>
>
>> -Original Message-
>> From: Development On Behalf Of Lars
>> Knoll
>
>
>> I’m not trying to make this only about emit. But it’s the concrete problem
>> we’re
>> facing now, and emit is IMO the one keyword where we simply
> -Original Message-
> From: Development On Behalf Of Lars
> Knoll
> I’m not trying to make this only about emit. But it’s the concrete problem
> we’re
> facing now, and emit is IMO the one keyword where we simply don’t need a
> replacement because it has no real semantic meaning in
Hi,
There are now 73 results to the survey, current results are at
https://bugreports.qt.io/secure/attachment/92413/survey_result.pdf
I tried to aggregate also the other suggestions, and ordering by absolute votes:
mySignal() - 21 votes
Q_EMIT mySignal() - 13 votes
[[qt::emit]] mySignal() -
26 matches
Mail list logo
