On Tuesday, 14 April 2020 20:54:57 -03 Nathan Myers wrote:
> I see that you are confused about the origins of Posix
> and Unix networking practices, as well as WG21's. ISO
> WG21 was convened in 1990. The ntohs etc. macros precede
> 1990. Qt does not.
Yes, it does. The first release was in 1994,
On 4/14/20 5:28 AM, Lars Knoll wrote:
On 14 Apr 2020, at 10:17, Nathan Myers
mailto:n...@cantrip.org>> wrote:
On 4/13/20 3:41 PM, Ville Voutilainen wrote:
It also doesn't require smoking crack to suggest that
WG21 considers code breakage due to new identifiers
clashing with existing
14.04.2020, 22:18, "Ville Voutilainen" :
> On Tue, 14 Apr 2020 at 12:31, Lars Knoll wrote:
>> What kind of argument is that? htons as a macro was worth considering, but
>> the ones in Qt are not?
>>
>> Fixing the htons macro also "only requires changing one place" in the
>> System C
On Tue, 14 Apr 2020 at 11:22, Nathan Myers wrote:
> Neither does Ville have authority to speak on behalf of
> the Library Evolution Working Group.
The slight difference, of course, is that I enumerated bits of
rationale that were actually uttered in that
discussion, rather than colorful
On Tue, 14 Apr 2020 at 12:31, Lars Knoll wrote:
> What kind of argument is that? htons as a macro was worth considering, but
> the ones in Qt are not?
>
> Fixing the htons macro also "only requires changing one place" in the System
> C library. You are forgetting, that both changes break a huge
On 14 Apr 2020, at 17:02, Matthew Woehlke
mailto:mwoehlke.fl...@gmail.com>> wrote:
On 14/04/2020 05.28, Lars Knoll wrote:
I believe there is mostly a consensus here to find a way to get rid
of those macros. But many of our users do seem to like the ‘emit’
keyword as an annotation to a signal
On 14/04/2020 05.28, Lars Knoll wrote:
I believe there is mostly a consensus here to find a way to get rid
of those macros. But many of our users do seem to like the ‘emit’
keyword as an annotation to a signal emission, and it is being used
extensively in existing code bases.
You know what
On 14 Apr 2020, at 10:17, Nathan Myers
mailto:n...@cantrip.org>> wrote:
On 4/13/20 3:41 PM, Ville Voutilainen wrote:
On Mon, 13 Apr 2020 at 06:11, Nathan Myers
mailto:n...@cantrip.org>> wrote:
The prevailing feeling in the room, when the vote was taken,
was that Qt people MUST BE SMOKING
On 4/13/20 3:41 PM, Ville Voutilainen wrote:
On Mon, 13 Apr 2020 at 06:11, Nathan Myers wrote:
The prevailing feeling in the room, when the vote was taken,
was that Qt people MUST BE SMOKING CRACK if they think
the ISO 14882 C++ Standard should or would tiptoe around Qt's
aggressive abuse
On Mon, 13 Apr 2020 at 06:11, Nathan Myers wrote:
> The prevailing feeling in the room, when the vote was taken,
> was that Qt people MUST BE SMOKING CRACK if they think
> the ISO 14882 C++ Standard should or would tiptoe around Qt's
> aggressive abuse of lower-case macro names. That Qt has
On Fri, Feb 21, 2020 at 11:03:19PM +0200, Ville Voutilainen wrote:
> On Fri, 21 Feb 2020 at 22:11, André Pönitz
> > wrote:
> > 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
On 28 Feb 2020, at 21:33, Lars Knoll
mailto:lars.kn...@qt.io>> wrote:
So to shortcut this discussion a bit: I am completely opposed to a massive SIC
changes/efforts for our signals (like giving them ugly names like
emitClicked(), or signal objects).
If people feel strongly, I am open to
On 02/03/2020 16:42, Matthew Woehlke wrote:
On 28/02/2020 15.33, Lars Knoll wrote:
This is all nice and fun to bike shed about, but I don’t think those
proposed solutions match the scope of the original problem (which
was relatively small). I don’t think a massive source compatibility
breakage
On 28/02/2020 15.33, Lars Knoll wrote:
> This is all nice and fun to bike shed about, but I don’t think those
> proposed solutions match the scope of the original problem (which
> was relatively small). I don’t think a massive source compatibility
> breakage is what we want, just because there is
On Monday, 2 March 2020 08:45:29 CET Jaroslaw Kobus wrote:
> Allan Sandfeld Jensen (27 February 2020 23:03) replied:
> > That is how I see it too. It essentially violates Qt code guidelines. If
> > it
> > was a normal method we would name it "emitEmptied()", so far we have just
> > lived with
___
From: Development on behalf of Edward
Welbourne
Sent: Friday, February 28, 2020 10:34 AM
To: Allan Sandfeld Jensen
Cc: development@qt-project.org
Subject: Re: [Development] A modest proposal: disable lower-case
keywords(emit, foreach, forever, signals, slots) by default
On
On Fri, 28 Feb 2020 at 22:35, Lars Knoll wrote:
> >> You'd see instead:
> >>this->emptied().emit(...);
> >>connect(foo, foo->emptied(), ...);
> > I like this, then we could finally (and without hacks) have protected and
> > private signals like in Qt 4.
> > Would also solve the need for
On Friday, 28 February 2020 16:28:34 CET Matthew Woehlke wrote:
> On 27/02/2020 17.03, Allan Sandfeld Jensen wrote:
> > On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote:
> >> On 26/02/2020 07.42, Tor Arne Vestbø wrote:
> >>> As others have argued, a signal is not special, in the
On Friday, 28 February 2020 12:12:35 PST Matthew Woehlke wrote:
> On 28/02/2020 13.39, Thiago Macieira wrote:
> > That's my point: it's a reasonable feature to ask that any good IDE
> > implement.
> It may be reasonable to ask *an IDE* to implement such a feature. It is
> *not* reasonable to ask
On Friday, 28 February 2020 12:06:06 PST Matthew Woehlke wrote:
> ...this might actually be better, since it would mean we still have MOC
> generating the code for the signal. (I was trying to figure out how MOC
> would generate the object initialization logic, and failing. I suspect
> this would
> On 28 Feb 2020, at 21:18, Sérgio Martins via Development
> wrote:
>
> On 2020-02-28 18:32, Thiago Macieira wrote:
>> On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote:
>>> If we had to do it over again, it might make sense to follow Python and
>>> make signals *objects* instead
On 2020-02-28 18:32, Thiago Macieira wrote:
On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote:
If we had to do it over again, it might make sense to follow Python
and
make signals *objects* instead of *methods*. Then the code would look
like:
this->emptied.emit(...);
Binary
On 28/02/2020 13.39, Thiago Macieira wrote:
> That's my point: it's a reasonable feature to ask that any good IDE implement.
It may be reasonable to ask *an IDE* to implement such a feature. It is
*not* reasonable to ask every place that developers look at code — some
of which don't even do basic
On 28/02/2020 13.37, Konstantin Tokarev wrote:
> 28.02.2020, 21:34, "Thiago Macieira" :
>> On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote:
>>> If we had to do it over again, it might make sense to follow Python and
>>> make signals *objects* instead of *methods*. Then the code
On 28/02/2020 13.32, Thiago Macieira wrote:
> On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote:
>> If we had to do it over again, it might make sense to follow Python and
>> make signals *objects* instead of *methods*. Then the code would look like:
>>
>> this->emptied.emit(...);
>
On Friday, 28 February 2020 07:24:32 PST Matthew Woehlke wrote:
> We aren't talking about recognizing `emit`. We're talking about being
> able to inspect the following code:
>
> if (...)
> {
> this->update();
> this->changed();
> }
>
> ...and recognizing that the former is a
28.02.2020, 21:34, "Thiago Macieira" :
> On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote:
>> If we had to do it over again, it might make sense to follow Python and
>> make signals *objects* instead of *methods*. Then the code would look like:
>>
>> this->emptied.emit(...);
>
On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote:
> If we had to do it over again, it might make sense to follow Python and
> make signals *objects* instead of *methods*. Then the code would look like:
>
> this->emptied.emit(...);
Binary compatibility issue: if it's a member of
On 27/02/2020 17.03, Allan Sandfeld Jensen wrote:
> On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote:
>> On 26/02/2020 07.42, Tor Arne Vestbø wrote:
>>> As others have argued, a signal is not special, in the sense that any
>>> function can do anything, including emitting signals,
On 27/02/2020 17.01, Allan Sandfeld Jensen wrote:
> On Thursday, 27 February 2020 21:43:33 CET Matthew Woehlke wrote:
>> On 27/02/2020 13.57, Thiago Macieira wrote:
>>> On Monday, 24 February 2020 03:30:25 PST André Somers wrote:
You seem to assume everyone used QtCreator as their IDE of
On Fri, 28 Feb 2020 at 10:35, Edward Welbourne
wrote:
>
>
> Indeed; most of the case for "emit" can be answered by a sensible naming
> convention.
>
One case where it does not work is in connections.
emit somethingWasDone() and emitSomethingWasDone() look similar.
But the emit in
On 26/02/2020 07.42, Tor Arne Vestbø wrote:
>>> As others have argued, a signal is not special, in the sense that any
>>> function can do anything, including emitting signals, so annotating it
>>> doesn’t seem critical, as we apparently are fine without in all other
>>> cases.
On Thursday, 27
On Monday, 24 February 2020 03:30:25 PST André Somers wrote:
You seem to assume everyone used QtCreator as their IDE of
choice. That is not a reasonable assumption I think.
On 27/02/2020 13.57, Thiago Macieira wrote:
>>> It is a reasonable feature request for ALL IDEs to understand what
On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote:
> On 26/02/2020 07.42, Tor Arne Vestbø wrote:
> > As others have argued, a signal is not special, in the sense that any
> > function can do anything, including emitting signals, so annotating it
> > doesn’t seem critical, as we
On Thursday, 27 February 2020 21:43:33 CET Matthew Woehlke wrote:
> On 27/02/2020 13.57, Thiago Macieira wrote:
> > On Monday, 24 February 2020 03:30:25 PST André Somers wrote:
> >> You seem to assume everyone used QtCreator as their IDE of choice. That
> >> is
> >> not a reasonable assumption I
On 26/02/2020 09.10, Oliver Wolff wrote:
> For me the emit has value. It's just an annotation, but for me it
> serves a purpose. I can see that this is a signal emission and even
> if people keep arguing that this is pointless it serves a purpose to
> me. "Look here a signal is emitted, so that
On 26/02/2020 07.42, Tor Arne Vestbø wrote:
> As others have argued, a signal is not special, in the sense that any
> function can do anything, including emitting signals, so annotating it
> doesn’t seem critical, as we apparently are fine without in all other cases.
Taking a step back... I
On 27/02/2020 13.57, Thiago Macieira wrote:
> On Monday, 24 February 2020 03:30:25 PST André Somers wrote:
>> You seem to assume everyone used QtCreator as their IDE of choice. That is
>> not a reasonable assumption I think.
>
> It is a reasonable feature request for ALL IDEs to understand what a
On Thursday, 27 February 2020 04:40:34 PST Ville Voutilainen wrote:
> The chance is very good; I talked about this with the maintainer of
> GCC already, and he was amenable to disabling
> an "unknown attribute" warning if the attribute has a namespace. For
> attributes that don't have namespaces,
On Wednesday, 26 February 2020 08:26:14 PST Alex Blasche wrote:
> > fooChanged(), and can perfectly well stand on their own, without
> > annotations. Corner cases like "emit pressed();” can be annotated with
> > Q_EMIT or a comment to make it clearer what’s going on.
>
>
> Some end with
On Monday, 24 February 2020 03:30:25 PST André Somers wrote:
> > In any case, I do understand why Qt added emit as a keyword 25 years ago.
> > But today, we do have IDEs which should be able to figure out on the fly
> > whether a function call is a signal emission (as they already do for
> >
On Tuesday, 25 February 2020 23:24:14 PST Lars Knoll wrote:
> The way it works is that in case more than one slot is connected to such a
> signal, the return value of the last slot connected is returned, if nothing
> is connected a default constructed value is returned.
The last DirectConnection
> I may need to write that patch myself.
Would you consider instead a patch introducing a builtin that allows a
library to declare attributes they "support" ?
eg something in the taste of __builtin_declare_valid_attribute("qt::emit");
A far cry from attribute creation abilities of languages such
On Thu, 27 Feb 2020 at 09:15, Alex Blasche wrote:
> >In general, implementations can still warn about pretty much whatever
> >they please, especially considering
> >that their default modes are not strictly conforming.
> >
> >The compilers we plan to support in Qt 6 do warn about unknown
>
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
t 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
>>>
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
> -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
gt; > Ville Voutilainen
> > Sent: Monday, February 24, 2020 2:53 PM
> > To: Lars Knoll
> > Cc: Thiago Macieira ; Qt development
> > mailing list
> > Subject: Re: [Development] A modest proposal: disable lower-case
> > keywords (emit, foreach, f
> On 24 Feb 2020, at 23:29, Marc Mutz wrote:
>
> Hi Lars, others,
>
> On 2020-02-24 12:25, Lars Knoll wrote:
>>> On 21 Feb 2020, at 17:39, Thiago Macieira wrote:
>>> On Friday, 21 February 2020 04:59:02 PST Ville Voutilainen wrote:
Having a keyword-extension to normal C++ is ugly as sin,
> On 25 Feb 2020, at 20:17, Matthew Woehlke wrote:
>
> On 21/02/2020 09.02, Ville Voutilainen wrote:
>> 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.
>
> AFAIK,
On Tue, 25 Feb 2020 at 10:19, Ville Voutilainen
wrote:
> Or perhaps qEmit(this)->my_signal(Args...);
>
> and hide the befriending of qEmit (so that private/protected don't
This doesn't even need friending.
#include
template
struct qEmit
{
T* that;
qEmit(T* it) : that(it) {}
T*
On Tue, 25 Feb 2020 at 22:17, Matthew Woehlke wrote:
> Right, and when I realized that, it got me wondering, how many people
> will need to call that specific function that are *also* using Qt *and*
> will be unwilling to use Q_NO_KEYWORDS to work around the issue?
You're getting back to the
On 25/02/2020 14.58, Ville Voutilainen wrote:
> On Tue, 25 Feb 2020 at 21:37, Matthew Woehlke wrote:
>> - Until now, `emit` has rarely been used in code that needs to mix with Qt.
>>
>> - C++20 will have modules.
>>
>> - Modules are theoretically immune to the above issue.
>
> Module definitions
On Tue, 25 Feb 2020 at 21:37, Matthew Woehlke wrote:
>
> On 24/02/2020 07.34, Edward Welbourne wrote:
> > Mitch Curtis (24 February 2020 13:22)
> >> I don't think anyone has explained what that harm is yet.
> >
> > #define emit
> >
> > causes problems when you import a header that declares
> >
>
On 24/02/2020 07.34, Edward Welbourne wrote:
> Mitch Curtis (24 February 2020 13:22)
>> I don't think anyone has explained what that harm is yet.
>
> #define emit
>
> causes problems when you import a header that declares
>
> void emit(Type arg);
>
> and the compiler sees
>
> void (Type
On 21/02/2020 09.02, Ville Voutilainen wrote:
> 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.
AFAIK, signals *can't* return, period. The signal body is written by
t;
>> Cc: Qt development mailing list > project.org <mailto:development@qt-project.org> >
>> Subject: Re: [Development] A modest proposal: disable
>> lower-case
>> keywords (emit, foreach, fo
On Tue, 25 Feb 2020 at 00:30, Marc Mutz via Development
wrote:
> Qt relies on macros a lot, and while I have not followed the latest
> Modules development, I'm sure macros pose a problem for a modularized
> Qt, too.
Header units can still export macros. Macros don't go into header
units or named
On Mon, 24 Feb 2020 at 17:17, Allan Sandfeld Jensen wrote:
> Yeah you would need something like qEmit(_signal, Args..) or without &
> using a macro. Or.. qEmit(std::bind(_signal, Args...));
Or perhaps qEmit(this)->my_signal(Args...);
and hide the befriending of qEmit (so that private/protected
Il 24/02/20 13:48, Mitch Curtis ha scritto:
In that case, I share the same concerns as Andre in that it requires IDEs to
have knowledge about Qt. I only use Creator, so it won't bother me, but it will
affect others who are e.g. transitioning or are so used to another IDE that
they'd never
Hi Lars, others,
On 2020-02-24 12:25, Lars Knoll wrote:
On 21 Feb 2020, at 17:39, Thiago Macieira
wrote:
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
24.02.2020, 18:19, "Allan Sandfeld Jensen" :
>
> Yeah you would need something like qEmit(_signal, Args..) or without &
> using a macro. Or.. qEmit(std::bind(_signal, Args...));
FWIW, using lambda expression is almost always a better solution that std::bind.
--
Regards,
Konstantin
modest proposal: disable lower-case keywords
> (emit, foreach, forever, signals, slots) by default
>
> On Mon, 24 Feb 2020 at 14:42, Lars Knoll wrote:
> > But we could convey the information that this is a signal you’re calling
> *reliably* through other means. Thi
On Monday, 24 February 2020 15:03:41 CET Ville Voutilainen wrote:
> On Mon, 24 Feb 2020 at 15:52, Ville Voutilainen
>
> wrote:
> > On Mon, 24 Feb 2020 at 14:42, Lars Knoll wrote:
> > > But we could convey the information that this is a signal you’re calling
> > > *reliably* through other means.
On Mon, 24 Feb 2020 at 15:52, Ville Voutilainen
wrote:
>
> On Mon, 24 Feb 2020 at 14:42, Lars Knoll wrote:
> > But we could convey the information that this is a signal you’re calling
> > *reliably* through other means. This implies that the keyword is not
> > required.
>
> Was the keyword
On Mon, 24 Feb 2020 at 14:42, Lars Knoll wrote:
> But we could convey the information that this is a signal you’re calling
> *reliably* through other means. This implies that the keyword is not required.
Was the keyword ever required? Seems like it's just a taste difference from a
On Mon, 24 Feb 2020 at 14:35, Mitch Curtis wrote:
> > > > > 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
> -Original Message-
> From: Edward Welbourne
> Sent: Monday, 24 February 2020 1:35 PM
> To: Mitch Curtis
> Cc: Qt development mailing list ; Lars Knoll
> ; Thiago Macieira
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, f
> -Original Message-
> From: Lars Knoll
> Sent: Monday, 24 February 2020 1:40 PM
> To: Mitch Curtis
> Cc: Thiago Macieira ; Qt development mailing
> list
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach, forever, si
com>>
Cc: Qt development mailing list
mailto: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 17:39, Thiago Macieira
mailto:thiago.macie...@intel.com>>
wrote
> -Original Message-
> From: Development On Behalf Of
> Ville Voutilainen
> Sent: Friday, 21 February 2020 3:02 PM
> To: Christian Kandeler
> Cc: development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, f
Mitch Curtis (24 February 2020 13:22)
> I don't think anyone has explained what that harm is yet.
#define emit
causes problems when you import a header that declares
void emit(Type arg);
and the compiler sees
void (Type arg);
and throws a wobbly.
Eddy.
> -Original Message-
> From: Development On Behalf Of
> Lars Knoll
> Sent: Monday, 24 February 2020 12:25 PM
> To: Thiago Macieira
> Cc: Qt development mailing list
> Subject: Re: [Development] A modest proposal: disable lower-case
> keywords (emit, foreach,
On 24 Feb 2020, at 12:30, André Somers
mailto:an...@familiesomers.nl>> wrote:
Hi Lars,
Sent from my phone, please excuse my brevity
On 24 Feb 2020, at 12:27, Lars Knoll
mailto:lars.kn...@qt.io>> wrote:
On 21 Feb 2020, at 17:39, Thiago Macieira
mailto:thiago.macie...@intel.com>> wrote:
Hi Lars,
Sent from my phone, please excuse my brevity
> On 24 Feb 2020, at 12:27, Lars Knoll wrote:
>
>
>>
>> On 21 Feb 2020, at 17:39, Thiago Macieira wrote:
>>
>>> On Friday, 21 February 2020 04:59:02 PST Ville Voutilainen wrote:
>>> Having a keyword-extension to normal C++ is ugly as
> On 21 Feb 2020, at 17:39, Thiago Macieira wrote:
>
> 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
> On 24 Feb 2020, at 10:54, Ville Voutilainen
> wrote:
>
> On Mon, 24 Feb 2020 at 11:23, Jean-Michaël Celerier
> wrote:
>>
>> A good inspiration for that feature would be the Just My Code feature of
>> recent visual studio :
>>
On Mon, 24 Feb 2020 at 11:23, Jean-Michaël Celerier
wrote:
>
> A good inspiration for that feature would be the Just My Code feature of
> recent visual studio :
> https://docs.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2019
That is indeed what I'm gunning for. :) If our
A good inspiration for that feature would be the Just My Code feature of
recent visual studio :
https://docs.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2019
Best,
Jean-Michaël
On Mon, Feb 24, 2020 at 8:51 AM Shawn Rutledge wrote:
>
> > On 22 Feb 2020, at 12:57, Ville
On 2020-02-21 17:31, Thiago Macieira wrote:
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"?
Both. I think the argument
> On 22 Feb 2020, at 12:57, Ville Voutilainen
> wrote:
>
> On Sat, 22 Feb 2020 at 13:07, André Pönitz wrote:
>>> Buy a debugger that can skip code that you didn't write.
>>
>> The point was that in a such a situation I, as user, would not even
>> try to step in when the call is marked with
On Sat, 22 Feb 2020 at 13:07, André Pönitz wrote:
> > Buy a debugger that can skip code that you didn't write.
>
> The point was that in a such a situation I, as user, would not even
> try to step in when the call is marked with 'emit'. This 'emit' in
> a line *is* valuable markup, that saves me
On Fri, Feb 21, 2020 at 11:03:19PM +0200, Ville Voutilainen wrote:
> On Fri, 21 Feb 2020 at 22:11, André Pönitz wrote:
> >
> > On Fri, Feb 21, 2020 at 04:02:04PM +0200, Ville Voutilainen wrote:
> > > > I, for one, definitely want to see whether I am emitting a signal or
> > > > not.
> > >
> > >
1 - 100 of 151 matches
Mail list logo
