Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[Elvis Stansvik]

Den lör 27 okt. 2018 kl 22:23 skrev Thiago Macieira :
>
> On Saturday, 27 October 2018 08:33:30 PDT Sérgio Martins wrote:
> > Should we instead just encourage people to make returnsQtContainer()
> > return a const container ?
>
> We should not, since the prevents move-construction from happening. You'll pay
> the cost of two reference counts (one up and one down).

Alright, rules that out I guess. From the looks of it, it could be ~100 ns.

Elvis

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Konstantin Shegunov]

On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira 
wrote:

> The answer to all of those questions needs to be "yes". Anything short of
> that
> means the CoC is powerless and just for show.
>

Which was my point exactly.


> Whether there's a termination of employment or not is out of scope, since
> the
> CoC does not rule TQtC employment and what other work there is inside that
> company.


> Note also it applies to any company. If you're not welcome anymore in the
> community where your employer is asking you to do work, that is going to
> affect your employment.
>

I agree. However my argument was that the QtC being a major contributor to
the codebase is going to have to abide by the ruling of the proposed
committee, which is a significant commitment (and a major nitpick I admit).
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[Thiago Macieira]

On Saturday, 27 October 2018 13:07:40 PDT Lars Knoll wrote:
> No need. He’s right. A move constructor only works with a non const value,
> as it needs to modify the object. One thing to check however for our
> containers is how much more expensive the copy is (compared to the move).

Two atomic operations.

https://stackoverflow.com/questions/2538070/atomic-operation-cost
https://stackoverflow.com/questions/34660376/atomic-fetch-add-vs-add-performance
etc.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



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

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[Thiago Macieira]

On Saturday, 27 October 2018 08:33:30 PDT Sérgio Martins wrote:
> Should we instead just encourage people to make returnsQtContainer()
> return a const container ?

We should not, since the prevents move-construction from happening. You'll pay 
the cost of two reference counts (one up and one down).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



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

Re: [Development] QUIP 12: Code of Conduct

[Thiago Macieira]

On Saturday, 27 October 2018 12:04:12 PDT Konstantin Shegunov wrote:
> Say we adopt the CC (basically the proposed text) and imagine that the
> abusive party is an employee of the QtC and has committed heinous acts
> against a community member. As far as I can tell this is very unlikely, but
> humor me for a second. As QtC employees' main work is on the Qt project,
> i.e. writing patches, committing features, writing docs and such, how would
> is this proposed committee to enforce the CoC? Are they going to plead that
> the person is taken out of the project, and wouldn't that mean that,
> basically, he/she can't be an employee for the QtC anymore? And to drive it
> home, say the head troll had a mental breakdown or something what is the
> committee to do? Take over the QtC?

The answer to all of those questions needs to be "yes". Anything short of that 
means the CoC is powerless and just for show.

Whether there's a termination of employment or not is out of scope, since the 
CoC does not rule TQtC employment and what other work there is inside that 
company.

Note also it applies to any company. If you're not welcome anymore in the 
community where your employer is asking you to do work, that is going to 
affect your employment.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



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

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[Lars Knoll]

On 27 Oct 2018, at 21:07, Elvis Stansvik 
mailto:elvst...@gmail.com>> wrote:

Den lör 27 okt. 2018 kl 19:48 skrev Lars Knoll 
mailto:lars.kn...@qt.io>>:



On 27 Oct 2018, at 19:29, André Pönitz 
mailto:apoen...@t-online.de>> wrote:

On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote:

On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik 
mailto:elvst...@gmail.com>> wrote:


Hi all (first post),


Welcome :)

In Qt 5.7+ there's qAsConst, an std::as_const implementation for those
who are not on C++17 yet, which is convenient for iterating over Qt
containers using range-based for loops without causing a detach.

For good reasons there's no version of qAsConst that takes an rvalue
reference, so you can't do e.g. for (auto foo :
qAsConst(returnsQtContainer())  { ... }. Instead you must do const
auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }.


Should we instead just encourage people to make returnsQtContainer()
return a const container ?


This is actually a route we recently took in some cases in Qt Creator's
code base.


That might actually make sense. Calling a non const method on the returned 
temporary object is usually a mistake anyway. And the copy/move assignment to a 
variable will work with the const object.

Hm, but was Marc not right when he said

 "Making returned containers const inhibits move semantics, because
const rvalues do not bind to the mutable rvalue references that move
constructors and move assignment operators use."

on his blog?

Guess he should jump in here to defend himself :)

No need. He’s right. A move constructor only works with a non const value, as 
it needs to modify the object. One thing to check however for our containers is 
how much more expensive the copy is (compared to the move).

Cheers,
Lars


Elvis


Cheers,
Lars

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

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

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[Elvis Stansvik]

Den lör 27 okt. 2018 kl 21:07 skrev Elvis Stansvik :
>
> Den lör 27 okt. 2018 kl 19:48 skrev Lars Knoll :
> >
> >
> >
> > On 27 Oct 2018, at 19:29, André Pönitz  wrote:
> >
> > On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote:
> >
> > On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik  wrote:
> >
> >
> > Hi all (first post),
> >
> >
> > Welcome :)
> >
> > In Qt 5.7+ there's qAsConst, an std::as_const implementation for those
> > who are not on C++17 yet, which is convenient for iterating over Qt
> > containers using range-based for loops without causing a detach.
> >
> > For good reasons there's no version of qAsConst that takes an rvalue
> > reference, so you can't do e.g. for (auto foo :
> > qAsConst(returnsQtContainer())  { ... }. Instead you must do const
> > auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }.
> >
> >
> > Should we instead just encourage people to make returnsQtContainer()
> > return a const container ?
> >
> >
> > This is actually a route we recently took in some cases in Qt Creator's
> > code base.
> >
> >
> > That might actually make sense. Calling a non const method on the returned 
> > temporary object is usually a mistake anyway. And the copy/move assignment 
> > to a variable will work with the const object.
>
> Hm, but was Marc not right when he said
>
>   "Making returned containers const inhibits move semantics, because
> const rvalues do not bind to the mutable rvalue references that move
> constructors and move assignment operators use."
>
> on his blog?
>
> Guess he should jump in here to defend himself :)

Another problem I found when trying to apply this to our code base is
that it seems you can't QtConcurrent::run a function returning const
T, because internally, ResultStoreBase::addResult looks like

template 
int addResult(int index, const T *result)
{
if (result == 0)
return addResult(index, static_cast(nullptr));
else
return addResult(index, static_cast(new T(*result)));
}

so you'll get an error like

/usr/include/x86_64-linux-gnu/qt5/QtCore/qresultstore.h:151: error:
static_cast from 'const QVector *' to 'void *' is not allowed
return addResult(index, static_cast(new T(*result)));
^~~

Just a small downside in our case, but still.

Elvis

>
> Elvis
>
> >
> > Cheers,
> > Lars
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[Elvis Stansvik]

Den lör 27 okt. 2018 kl 19:48 skrev Lars Knoll :
>
>
>
> On 27 Oct 2018, at 19:29, André Pönitz  wrote:
>
> On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote:
>
> On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik  wrote:
>
>
> Hi all (first post),
>
>
> Welcome :)
>
> In Qt 5.7+ there's qAsConst, an std::as_const implementation for those
> who are not on C++17 yet, which is convenient for iterating over Qt
> containers using range-based for loops without causing a detach.
>
> For good reasons there's no version of qAsConst that takes an rvalue
> reference, so you can't do e.g. for (auto foo :
> qAsConst(returnsQtContainer())  { ... }. Instead you must do const
> auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }.
>
>
> Should we instead just encourage people to make returnsQtContainer()
> return a const container ?
>
>
> This is actually a route we recently took in some cases in Qt Creator's
> code base.
>
>
> That might actually make sense. Calling a non const method on the returned 
> temporary object is usually a mistake anyway. And the copy/move assignment to 
> a variable will work with the const object.

Hm, but was Marc not right when he said

  "Making returned containers const inhibits move semantics, because
const rvalues do not bind to the mutable rvalue references that move
constructors and move assignment operators use."

on his blog?

Guess he should jump in here to defend himself :)

Elvis

>
> Cheers,
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Konstantin Shegunov]

On Sat, Oct 27, 2018 at 4:56 PM Martin Smith  wrote:

> You just specified a code of conduct. The problem with your code of
> conduct is that it isn't guaranteed to end in resolution.
>

Oh, it is going to end in A resolution, it may not end the way the offended
party may feel just, but that's true also for the proposed text.


> But that isn't the implication.
>

Then I apologize, this is how I interpreted it.

The implication is that a mistreated person can take the actions you have
> specified, and the result can be that the mistreatment, real or not, is not
> resolved.


The proposed text can't guarantee resolution either (see below for a
reductio ad absurdum).

Active contributors who abuse others should be treated the same as inactive
> contributors who abuse others. What would be done would of course depend on
> what the abuser did. I suppose the abuser (active contributor or not) would
> be informed as to what he/she did wrong and would be told to stop doing it.


Say we adopt the CC (basically the proposed text) and imagine that the
abusive party is an employee of the QtC and has committed heinous acts
against a community member. As far as I can tell this is very unlikely, but
humor me for a second. As QtC employees' main work is on the Qt project,
i.e. writing patches, committing features, writing docs and such, how would
is this proposed committee to enforce the CoC? Are they going to plead that
the person is taken out of the project, and wouldn't that mean that,
basically, he/she can't be an employee for the QtC anymore? And to drive it
home, say the head troll had a mental breakdown or something what is the
committee to do? Take over the QtC?

Just as I said before, I'm not against a CoC in principle. I'm against the
CC's text which is quite invasive and badly written. To me KDE's CoC is
much more practical in the case of the Qt project.

Exactly. Without a CoC, we have no laws, so the implication is we don't
> consider any behavior an offense.


Laws are bit more complicated than a statement of how people *should*
behave. There's also separation of power, mandates, enforcement and laws
that control how laws are made. Also there's hierarchy between the laws
themselves in case they are in conflict. I suggest we don't venture into
that. It's not what binds us to this community to begin with.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[André Pönitz]

On Sat, Oct 27, 2018 at 05:34:30PM +, Martin Smith wrote:
> >Actions that are considered offenses by a society are typically mentioned
> >in its laws. If something is not forbidden by law it usually means that
> >there is no majority, let alone consensus in that society that this action
> >is an offense.
> 
> Exactly. Without a CoC, we have no laws, so the implication
> is we don't consider any behavior an offense.

I am not aware of a single country without laws.

Over here e.g. "insult" is an offense.

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

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[Lars Knoll]

On 27 Oct 2018, at 19:29, André Pönitz 
mailto:apoen...@t-online.de>> wrote:

On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote:
On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik 
mailto:elvst...@gmail.com>> wrote:

Hi all (first post),

Welcome :)

In Qt 5.7+ there's qAsConst, an std::as_const implementation for those
who are not on C++17 yet, which is convenient for iterating over Qt
containers using range-based for loops without causing a detach.

For good reasons there's no version of qAsConst that takes an rvalue
reference, so you can't do e.g. for (auto foo :
qAsConst(returnsQtContainer())  { ... }. Instead you must do const
auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }.

Should we instead just encourage people to make returnsQtContainer()
return a const container ?

This is actually a route we recently took in some cases in Qt Creator's
code base.

That might actually make sense. Calling a non const method on the returned 
temporary object is usually a mistake anyway. And the copy/move assignment to a 
variable will work with the const object.

Cheers,
Lars

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

Re: [Development] QUIP 12: Code of Conduct

[Martin Smith]

>Actions that are considered offenses by a society are typically mentioned
>in its laws. If something is not forbidden by law it usually means that
>there is no majority, let alone consensus in that society that this action
>is an offense.

Exactly. Without a CoC, we have no laws, so the implication is we don't 
consider any behavior an offense.


From: André Pönitz 
Sent: Saturday, October 27, 2018 7:25:39 PM
To: Martin Smith
Cc: Bernhard Lindner; development@qt-project.org
Subject: Re: [Development] QUIP 12: Code of Conduct

On Sat, Oct 27, 2018 at 01:09:45PM +, Martin Smith wrote:
> >Well, then let me give you my simple minded opinion on this topic, an 
> >engineers
> >opinion:
> >Do not introduce a CoC.
>
> In that case, if a contributor is mistreated by another contributor,
> what recourse does the victim have?

File charges with the relevant authorities.

Why should "being a contributor" make a difference?

Actions that are considered offenses by a society are typically mentioned
in its laws. If something is not forbidden by law it usually means that
there is no majority, let alone consensus in that society that this action
is an offense.


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

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[André Pönitz]

On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote:
> On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik  wrote:
> >
> > Hi all (first post),
> 
> Welcome :)
> 
> > In Qt 5.7+ there's qAsConst, an std::as_const implementation for those
> > who are not on C++17 yet, which is convenient for iterating over Qt
> > containers using range-based for loops without causing a detach.
> >
> > For good reasons there's no version of qAsConst that takes an rvalue
> > reference, so you can't do e.g. for (auto foo :
> > qAsConst(returnsQtContainer())  { ... }. Instead you must do const
> > auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }.
> 
> Should we instead just encourage people to make returnsQtContainer()
> return a const container ?

This is actually a route we recently took in some cases in Qt Creator's
code base.

Andre'

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

Re: [Development] QUIP 12: Code of Conduct

[André Pönitz]

On Sat, Oct 27, 2018 at 01:09:45PM +, Martin Smith wrote:
> >Well, then let me give you my simple minded opinion on this topic, an 
> >engineers
> >opinion:
> >Do not introduce a CoC.
> 
> In that case, if a contributor is mistreated by another contributor,
> what recourse does the victim have?

File charges with the relevant authorities.

Why should "being a contributor" make a difference?

Actions that are considered offenses by a society are typically mentioned
in its laws. If something is not forbidden by law it usually means that
there is no majority, let alone consensus in that society that this action
is an offense.


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

Re: [Development] QUIP 12: Code of Conduct

[Alexey Andreyev]

Want to add that CoC implementation matters.
It's hard to accept and change or revert some rules than.

The controversial discrimination protection sentences at least should be
carefully discussed. It's not some thing that we could accept as easy as
rewrite.

сб, 27 окт. 2018 г., 18:51 Martin Smith :

> Having observed this discussion since the beginning...
>
> Apparently there are cases where contributors are being abused by other
> contributors. Currently, there is no formal procedure for resolving these
> cases of alleged abuse.
>
> Those objecting to establishing a CoC the purpose of which will be to
> establish that formal procedure to resolve cases of alleged dispute, are
> objecting because the CoC might abuse someone accused of abuse.
>
> Those objecting claim we are all able to resolve these abuse problems
> without a code of conduct, but those of us empowered, under a CoC, to
> resolve cases of abuse, would suddenly lose their ability to resolve abuse
> problems and would instead use the CoC to abuse alleged abusers.
>
> That's what it looks like to me.
>
> 
> From: Alexey Andreyev 
> Sent: Saturday, October 27, 2018 5:21:10 PM
> To: Martin Smith
> Cc: NIkolai “Zeks” Marchenko; Qt development mailing list
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> I agree not interacting is probably not a solution and your contribution
> without other details is not an excuse.
>
> But I think existing CoC have problems.
> There are statements everywhere about discrimination protection for
> example which are very controversial.
>
> The problem with that in other communities was already mentioned.
> I disagree it's not a big deal and have more benefits than negative aspect.
> We provided a lot of problematic real-life examples, since it's still hard
> to prove positive impact.
>
> I guess we should try to develop better version, I don't see real-life
> benefits from existing CoC at other communities.
>
>
> сб, 27 окт. 2018 г., 17:53 Martin Smith  martin.sm...@qt.io>>:
> >I am yet to hear an answer about what is going to be done in case the
> person
> >mistreating is an active contributor.
> >Will you chose potential harm, over actual benefit of having such a
> person on the
> >project?
>
> Active contributors who abuse others should be treated the same as
> inactive contributors who abuse others. What would be done would of course
> depend on what the abuser did. I suppose the abuser (active contributor or
> not) would be informed as to what he/she did wrong and would be told to
> stop doing it.
>
> Your remarks seem to mean you would rather ignore harm to get the benefit.
> I hope that's not what you mean. Being a super contributor doesn't buy one
> the privilege of being an asshole to others.
>
> 
> From: NIkolai Marchenko  enmarantis...@gmail.com>>
> Sent: Saturday, October 27, 2018 4:03:41 PM
> To: Martin Smith
> Cc: Konstantin Shegunov; Qt development mailing list
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> I am yet to hear an answer about what is going to be done in case the
> person mistreating is an active contributor.
> Will you chose potential harm, over actual benefit of having such a person
> on the project?
>
> The edge case being, for example, if a module maintainer is mistreating
> someone for whatever reason.
> The other person can just stop trying to interact with that maintainer,
> but I fail to see how removing a maintainer over a potential benefit of
> someone not being mistreated actually benefits the project.
>
> I've heard from people in this thread that it _is_ a problem you are
> trying to sovle and there _have _ been mistreatment.
> Now, I am not asking for dirty laundry, but isn't community supposed to
> know at least in broad strokes, the kind of problems yo uare even tring to
> solve before actually voting on anything?
> Maybe the community have a better answer for these specific problems?
>
> On Sat, Oct 27, 2018 at 4:56 PM Martin Smith  martin.sm...@qt.io>>>
> wrote:
>
> >1) To contact the contributor first and try to resolve the issue civilly.
> >2) To seek help with a third party (another contributor) who is known to
> the
> >alleged victim and who can act as mediator to try an resolve it.
> >3) If 1) and 2) don't work he/she may also bring it to the attention of
> the
> >community (e.g. the mailing list). The community is then free to react or
> not to
> >react.
>
> You just specified a code of conduct. The problem with your code of
> conduct is that it isn't guaranteed to end in resolution.
>
> >The implication that currently, if you're feeling mistreated, it's
> impossible to act
> >(respectfully) against harassment seems rather far-fetched to me.
>
> But that isn't the implication. The implication is that a mistreated
> person can take the actions you have specified, and the result can be that
> the mistreatment, real 

Re: [Development] QUIP 12: Code of Conduct

[Martin Smith]

Having observed this discussion since the beginning...

Apparently there are cases where contributors are being abused by other 
contributors. Currently, there is no formal procedure for resolving these cases 
of alleged abuse.

Those objecting to establishing a CoC the purpose of which will be to establish 
that formal procedure to resolve cases of alleged dispute, are objecting 
because the CoC might abuse someone accused of abuse.

Those objecting claim we are all able to resolve these abuse problems without a 
code of conduct, but those of us empowered, under a CoC, to resolve cases of 
abuse, would suddenly lose their ability to resolve abuse problems and would 
instead use the CoC to abuse alleged abusers.

That's what it looks like to me.


From: Alexey Andreyev 
Sent: Saturday, October 27, 2018 5:21:10 PM
To: Martin Smith
Cc: NIkolai “Zeks” Marchenko; Qt development mailing list
Subject: Re: [Development] QUIP 12: Code of Conduct

I agree not interacting is probably not a solution and your contribution 
without other details is not an excuse.

But I think existing CoC have problems.
There are statements everywhere about discrimination protection for example 
which are very controversial.

The problem with that in other communities was already mentioned.
I disagree it's not a big deal and have more benefits than negative aspect.
We provided a lot of problematic real-life examples, since it's still hard to 
prove positive impact.

I guess we should try to develop better version, I don't see real-life benefits 
from existing CoC at other communities.


сб, 27 окт. 2018 г., 17:53 Martin Smith 
mailto:martin.sm...@qt.io>>:
>I am yet to hear an answer about what is going to be done in case the person
>mistreating is an active contributor.
>Will you chose potential harm, over actual benefit of having such a person on 
>the
>project?

Active contributors who abuse others should be treated the same as inactive 
contributors who abuse others. What would be done would of course depend on 
what the abuser did. I suppose the abuser (active contributor or not) would be 
informed as to what he/she did wrong and would be told to stop doing it.

Your remarks seem to mean you would rather ignore harm to get the benefit. I 
hope that's not what you mean. Being a super contributor doesn't buy one the 
privilege of being an asshole to others.


From: NIkolai Marchenko 
mailto:enmarantis...@gmail.com>>
Sent: Saturday, October 27, 2018 4:03:41 PM
To: Martin Smith
Cc: Konstantin Shegunov; Qt development mailing list
Subject: Re: [Development] QUIP 12: Code of Conduct

I am yet to hear an answer about what is going to be done in case the person 
mistreating is an active contributor.
Will you chose potential harm, over actual benefit of having such a person on 
the project?

The edge case being, for example, if a module maintainer is mistreating someone 
for whatever reason.
The other person can just stop trying to interact with that maintainer, but I 
fail to see how removing a maintainer over a potential benefit of someone not 
being mistreated actually benefits the project.

I've heard from people in this thread that it _is_ a problem you are trying to 
sovle and there _have _ been mistreatment.
Now, I am not asking for dirty laundry, but isn't community supposed to know at 
least in broad strokes, the kind of problems yo uare even tring to solve before 
actually voting on anything?
Maybe the community have a better answer for these specific problems?

On Sat, Oct 27, 2018 at 4:56 PM Martin Smith 
mailto:martin.sm...@qt.io>>>
 wrote:

>1) To contact the contributor first and try to resolve the issue civilly.
>2) To seek help with a third party (another contributor) who is known to the
>alleged victim and who can act as mediator to try an resolve it.
>3) If 1) and 2) don't work he/she may also bring it to the attention of the
>community (e.g. the mailing list). The community is then free to react or not 
>to
>react.

You just specified a code of conduct. The problem with your code of conduct is 
that it isn't guaranteed to end in resolution.

>The implication that currently, if you're feeling mistreated, it's impossible 
>to act
>(respectfully) against harassment seems rather far-fetched to me.

But that isn't the implication. The implication is that a mistreated person can 
take the actions you have specified, and the result can be that the 
mistreatment, real or not, is not resolved.


From: Konstantin Shegunov 
mailto:kshegu...@gmail.com>>>
Sent: Saturday, October 27, 2018 3:48:49 PM
To: Martin Smith
Cc: 
development@qt-project.org>
Subject: Re: [Development] QUIP 12: Code of Conduct

On Sat, 

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[Elvis Stansvik]

Den lör 27 okt. 2018 kl 17:33 skrev Sérgio Martins :
>
> On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik  wrote:
> >
> > Hi all (first post),
>
> Welcome :)
>
> > In Qt 5.7+ there's qAsConst, an std::as_const implementation for those
> > who are not on C++17 yet, which is convenient for iterating over Qt
> > containers using range-based for loops without causing a detach.
> >
> > For good reasons there's no version of qAsConst that takes an rvalue
> > reference, so you can't do e.g. for (auto foo :
> > qAsConst(returnsQtContainer())  { ... }. Instead you must do const
> > auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }.
>
> Should we instead just encourage people to make returnsQtContainer()
> return a const container ?
> Not sure what's the reason we don't do it in Qt. It's frowned upon for
> regular value types, but our containers are special.

It was the very last comment on that blog post, to which Marc
answered: "Making returned containers const inhibits move semantics,
because const rvalues do not bind to the mutable rvalue references
that move constructors and move assignment operators use."

Elvis

>
> Regards,
> Sergio
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[Sérgio Martins]

On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik  wrote:
>
> Hi all (first post),

Welcome :)

> In Qt 5.7+ there's qAsConst, an std::as_const implementation for those
> who are not on C++17 yet, which is convenient for iterating over Qt
> containers using range-based for loops without causing a detach.
>
> For good reasons there's no version of qAsConst that takes an rvalue
> reference, so you can't do e.g. for (auto foo :
> qAsConst(returnsQtContainer())  { ... }. Instead you must do const
> auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }.

Should we instead just encourage people to make returnsQtContainer()
return a const container ?
Not sure what's the reason we don't do it in Qt. It's frowned upon for
regular value types, but our containers are special.

Regards,
Sergio
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[Sérgio Martins]

> Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart :
> > Jokes aside, I think we still should let users use Q_FOREACH for implicitly
> > shared containers.

But what's the percentage of Qt developers that understand the
subtleties between Q_FOREACH and range-for ?
Having a toolbox with two similar-but-not-quite constructs is bad for
less seasoned users.
I prefer explicitly assigning the container to a const local variable
instead of relying in the magic behind macros.

On Sat, Oct 27, 2018 at 1:53 PM Elvis Stansvik  wrote:
> Yes, I thought that Q_FOREACH was slated for deprecation though. But
> maybe that's not set in stone yet?

It is, see Qt's documentation:
"Since Qt 5.7, the use of this macro is discouraged. It will be
removed in a future version of Qt"


Regards,
Sérgio
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Alexey Andreyev]

I agree not interacting is probably not a solution and your contribution
without other details is not an excuse.

But I think existing CoC have problems.
There are statements everywhere about discrimination protection for example
which are very controversial.

The problem with that in other communities was already mentioned.
I disagree it's not a big deal and have more benefits than negative aspect.
We provided a lot of problematic real-life examples, since it's still hard
to prove positive impact.

I guess we should try to develop better version, I don't see real-life
benefits from existing CoC at other communities.


сб, 27 окт. 2018 г., 17:53 Martin Smith :

> >I am yet to hear an answer about what is going to be done in case the
> person
> >mistreating is an active contributor.
> >Will you chose potential harm, over actual benefit of having such a
> person on the
> >project?
>
> Active contributors who abuse others should be treated the same as
> inactive contributors who abuse others. What would be done would of course
> depend on what the abuser did. I suppose the abuser (active contributor or
> not) would be informed as to what he/she did wrong and would be told to
> stop doing it.
>
> Your remarks seem to mean you would rather ignore harm to get the benefit.
> I hope that's not what you mean. Being a super contributor doesn't buy one
> the privilege of being an asshole to others.
>
> 
> From: NIkolai Marchenko 
> Sent: Saturday, October 27, 2018 4:03:41 PM
> To: Martin Smith
> Cc: Konstantin Shegunov; Qt development mailing list
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> I am yet to hear an answer about what is going to be done in case the
> person mistreating is an active contributor.
> Will you chose potential harm, over actual benefit of having such a person
> on the project?
>
> The edge case being, for example, if a module maintainer is mistreating
> someone for whatever reason.
> The other person can just stop trying to interact with that maintainer,
> but I fail to see how removing a maintainer over a potential benefit of
> someone not being mistreated actually benefits the project.
>
> I've heard from people in this thread that it _is_ a problem you are
> trying to sovle and there _have _ been mistreatment.
> Now, I am not asking for dirty laundry, but isn't community supposed to
> know at least in broad strokes, the kind of problems yo uare even tring to
> solve before actually voting on anything?
> Maybe the community have a better answer for these specific problems?
>
> On Sat, Oct 27, 2018 at 4:56 PM Martin Smith  martin.sm...@qt.io>> wrote:
>
> >1) To contact the contributor first and try to resolve the issue civilly.
> >2) To seek help with a third party (another contributor) who is known to
> the
> >alleged victim and who can act as mediator to try an resolve it.
> >3) If 1) and 2) don't work he/she may also bring it to the attention of
> the
> >community (e.g. the mailing list). The community is then free to react or
> not to
> >react.
>
> You just specified a code of conduct. The problem with your code of
> conduct is that it isn't guaranteed to end in resolution.
>
> >The implication that currently, if you're feeling mistreated, it's
> impossible to act
> >(respectfully) against harassment seems rather far-fetched to me.
>
> But that isn't the implication. The implication is that a mistreated
> person can take the actions you have specified, and the result can be that
> the mistreatment, real or not, is not resolved.
>
> 
> From: Konstantin Shegunov mailto:kshegu...@gmail.com
> >>
> Sent: Saturday, October 27, 2018 3:48:49 PM
> To: Martin Smith
> Cc: development@qt-project.org
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Sat, Oct 27, 2018 at 4:09 PM Martin Smith  martin.sm...@qt.io>>>
> wrote:
> In that case, if a contributor is mistreated by another contributor, what
> recourse does the victim have?
>
> 1) To contact the contributor first and try to resolve the issue civilly.
> 2) To seek help with a third party (another contributor) who is known to
> the alleged victim and who can act as mediator to try an resolve it.
> 3) If 1) and 2) don't work he/she may also bring it to the attention of
> the community (e.g. the mailing list). The community is then free to react
> or not to react.
>
> The implication that currently, if you're feeling mistreated, it's
> impossible to act (respectfully) against harassment seems rather
> far-fetched to me.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> 

Re: [Development] QUIP 12: Code of Conduct

[Martin Smith]

>I am yet to hear an answer about what is going to be done in case the person
>mistreating is an active contributor.
>Will you chose potential harm, over actual benefit of having such a person on 
>the
>project?

Active contributors who abuse others should be treated the same as inactive 
contributors who abuse others. What would be done would of course depend on 
what the abuser did. I suppose the abuser (active contributor or not) would be 
informed as to what he/she did wrong and would be told to stop doing it.

Your remarks seem to mean you would rather ignore harm to get the benefit. I 
hope that's not what you mean. Being a super contributor doesn't buy one the 
privilege of being an asshole to others.


From: NIkolai Marchenko 
Sent: Saturday, October 27, 2018 4:03:41 PM
To: Martin Smith
Cc: Konstantin Shegunov; Qt development mailing list
Subject: Re: [Development] QUIP 12: Code of Conduct

I am yet to hear an answer about what is going to be done in case the person 
mistreating is an active contributor.
Will you chose potential harm, over actual benefit of having such a person on 
the project?

The edge case being, for example, if a module maintainer is mistreating someone 
for whatever reason.
The other person can just stop trying to interact with that maintainer, but I 
fail to see how removing a maintainer over a potential benefit of someone not 
being mistreated actually benefits the project.

I've heard from people in this thread that it _is_ a problem you are trying to 
sovle and there _have _ been mistreatment.
Now, I am not asking for dirty laundry, but isn't community supposed to know at 
least in broad strokes, the kind of problems yo uare even tring to solve before 
actually voting on anything?
Maybe the community have a better answer for these specific problems?

On Sat, Oct 27, 2018 at 4:56 PM Martin Smith 
mailto:martin.sm...@qt.io>> wrote:

>1) To contact the contributor first and try to resolve the issue civilly.
>2) To seek help with a third party (another contributor) who is known to the
>alleged victim and who can act as mediator to try an resolve it.
>3) If 1) and 2) don't work he/she may also bring it to the attention of the
>community (e.g. the mailing list). The community is then free to react or not 
>to
>react.

You just specified a code of conduct. The problem with your code of conduct is 
that it isn't guaranteed to end in resolution.

>The implication that currently, if you're feeling mistreated, it's impossible 
>to act
>(respectfully) against harassment seems rather far-fetched to me.

But that isn't the implication. The implication is that a mistreated person can 
take the actions you have specified, and the result can be that the 
mistreatment, real or not, is not resolved.


From: Konstantin Shegunov mailto:kshegu...@gmail.com>>
Sent: Saturday, October 27, 2018 3:48:49 PM
To: Martin Smith
Cc: development@qt-project.org
Subject: Re: [Development] QUIP 12: Code of Conduct

On Sat, Oct 27, 2018 at 4:09 PM Martin Smith 
mailto:martin.sm...@qt.io>>>
 wrote:
In that case, if a contributor is mistreated by another contributor, what 
recourse does the victim have?

1) To contact the contributor first and try to resolve the issue civilly.
2) To seek help with a third party (another contributor) who is known to the 
alleged victim and who can act as mediator to try an resolve it.
3) If 1) and 2) don't work he/she may also bring it to the attention of the 
community (e.g. the mailing list). The community is then free to react or not 
to react.

The implication that currently, if you're feeling mistreated, it's impossible 
to act (respectfully) against harassment seems rather far-fetched to me.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[NIkolai Marchenko]

I am yet to hear an answer about what is going to be done in case the
person mistreating is an active contributor.
Will you chose potential harm, over actual benefit of having such a person
on the project?

The edge case being, for example, if a module maintainer is mistreating
someone for whatever reason.
The other person can just stop trying to interact with that maintainer, but
I fail to see how removing a maintainer over a potential benefit of someone
not being mistreated actually benefits the project.

I've heard from people in this thread that it _is_ a problem you are trying
to sovle and there _have _ been mistreatment.
Now, I am not asking for dirty laundry, but isn't community supposed to
know at least in broad strokes, the kind of problems yo uare even tring to
solve before actually voting on anything?
Maybe the community have a better answer for these specific problems?

On Sat, Oct 27, 2018 at 4:56 PM Martin Smith  wrote:

>
> >1) To contact the contributor first and try to resolve the issue civilly.
> >2) To seek help with a third party (another contributor) who is known to
> the
> >alleged victim and who can act as mediator to try an resolve it.
> >3) If 1) and 2) don't work he/she may also bring it to the attention of
> the
> >community (e.g. the mailing list). The community is then free to react or
> not to
> >react.
>
> You just specified a code of conduct. The problem with your code of
> conduct is that it isn't guaranteed to end in resolution.
>
> >The implication that currently, if you're feeling mistreated, it's
> impossible to act
> >(respectfully) against harassment seems rather far-fetched to me.
>
> But that isn't the implication. The implication is that a mistreated
> person can take the actions you have specified, and the result can be that
> the mistreatment, real or not, is not resolved.
>
> 
> From: Konstantin Shegunov 
> Sent: Saturday, October 27, 2018 3:48:49 PM
> To: Martin Smith
> Cc: development@qt-project.org
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Sat, Oct 27, 2018 at 4:09 PM Martin Smith  martin.sm...@qt.io>> wrote:
> In that case, if a contributor is mistreated by another contributor, what
> recourse does the victim have?
>
> 1) To contact the contributor first and try to resolve the issue civilly.
> 2) To seek help with a third party (another contributor) who is known to
> the alleged victim and who can act as mediator to try an resolve it.
> 3) If 1) and 2) don't work he/she may also bring it to the attention of
> the community (e.g. the mailing list). The community is then free to react
> or not to react.
>
> The implication that currently, if you're feeling mistreated, it's
> impossible to act (respectfully) against harassment seems rather
> far-fetched to me.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Martin Smith]

>1) To contact the contributor first and try to resolve the issue civilly.
>2) To seek help with a third party (another contributor) who is known to the
>alleged victim and who can act as mediator to try an resolve it.
>3) If 1) and 2) don't work he/she may also bring it to the attention of the
>community (e.g. the mailing list). The community is then free to react or not 
>to
>react.

You just specified a code of conduct. The problem with your code of conduct is 
that it isn't guaranteed to end in resolution.

>The implication that currently, if you're feeling mistreated, it's impossible 
>to act
>(respectfully) against harassment seems rather far-fetched to me.

But that isn't the implication. The implication is that a mistreated person can 
take the actions you have specified, and the result can be that the 
mistreatment, real or not, is not resolved.


From: Konstantin Shegunov 
Sent: Saturday, October 27, 2018 3:48:49 PM
To: Martin Smith
Cc: development@qt-project.org
Subject: Re: [Development] QUIP 12: Code of Conduct

On Sat, Oct 27, 2018 at 4:09 PM Martin Smith 
mailto:martin.sm...@qt.io>> wrote:
In that case, if a contributor is mistreated by another contributor, what 
recourse does the victim have?

1) To contact the contributor first and try to resolve the issue civilly.
2) To seek help with a third party (another contributor) who is known to the 
alleged victim and who can act as mediator to try an resolve it.
3) If 1) and 2) don't work he/she may also bring it to the attention of the 
community (e.g. the mailing list). The community is then free to react or not 
to react.

The implication that currently, if you're feeling mistreated, it's impossible 
to act (respectfully) against harassment seems rather far-fetched to me.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Konstantin Shegunov]

On Sat, Oct 27, 2018 at 4:09 PM Martin Smith  wrote:

> In that case, if a contributor is mistreated by another contributor, what
> recourse does the victim have?
>

1) To contact the contributor first and try to resolve the issue civilly.
2) To seek help with a third party (another contributor) who is known to
the alleged victim and who can act as mediator to try an resolve it.
3) If 1) and 2) don't work he/she may also bring it to the attention of the
community (e.g. the mailing list). The community is then free to react or
not to react.

The implication that currently, if you're feeling mistreated, it's
impossible to act (respectfully) against harassment seems rather
far-fetched to me.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[Elvis Stansvik]

Den lör 27 okt. 2018 kl 15:06 skrev Kevin Kofler :
>
> Elvis Stansvik wrote:
> > Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart :
> >> Jokes aside, I think we still should let users use Q_FOREACH for
> >> implicitly shared containers.
> >
> > Yes, I thought that Q_FOREACH was slated for deprecation though. But
> > maybe that's not set in stone yet?
>
> That's his point, it should be undeprecated.

Ah, now I see.

I finally managed to read all the comments on that post, and I
definitely don't want to open that can of worms here again.

I'm fine with Guiseppes answers to my initial question, a qMoveToConst
probably wasn't a good idea in the first place.

Elvis

>
> Kevin Kofler
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Martin Smith]

>Note that installing a conflict resolution authority doesn't need installing a
>controversial CoC and formalizing every thing a contributor can or cannot do..

But it does require specifying how to lodge a complaint, which specifies 
conduct, and it then ought to say something about the kinds of complaints that 
will be resolved by the resolution authority and the kinds of complaints that 
will not. That also specifies conduct.

>but aren't people in this project sensible enough, in general, to have the
>common sense to reach an adequate solution?

That's what we're doing now.


From: NIkolai Marchenko 
Sent: Saturday, October 27, 2018 3:17:09 PM
To: Martin Smith
Cc: priv...@bernhard-lindner.de; Qt development mailing list
Subject: Re: [Development] QUIP 12: Code of Conduct

Note that installing a conflict resolution authority doesn't need installing a 
controversial CoC and formalizing every thing a contributor can or cannot do..
True, there won't be formalized and standadized rules for resolution, but 
aren't people in this project sensible enough, in general, to have the common 
sense to reach an adequate solution?

On Sat, Oct 27, 2018 at 4:10 PM Martin Smith 
mailto:martin.sm...@qt.io>> wrote:
>Well, then let me give you my simple minded opinion on this topic, an engineers
>opinion:
>Do not introduce a CoC.

In that case, if a contributor is mistreated by another contributor, what 
recourse does the victim have?

martin


From: Development 
mailto:qt...@qt-project.org>>
 on behalf of Bernhard Lindner 
mailto:priv...@bernhard-lindner.de>>
Sent: Saturday, October 27, 2018 12:39:40 AM
To: development@qt-project.org
Subject: Re: [Development] QUIP 12: Code of Conduct

> But the only mailing list with sufficient representation of the community is
> this one. We don't have to like discussing this, but it seems necessary that
> we do.

Well, then let me give you my simple minded opinion on this topic, an engineers 
opinion:
Do not introduce a CoC.

Resisting to have anything and everything in black and white is hard and is not 
popular
and surely not zeitgeist but sometimes the better way.

Please do not make me discuss about that as well, I prefer to wrangle with item 
delegate
code ;)

--
Best regards,
Bernhard Lindner

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

Re: [Development] QUIP 12: Code of Conduct

[NIkolai Marchenko]

Note that installing a conflict resolution authority doesn't need
installing a controversial CoC and formalizing every thing a contributor
can or cannot do..
True, there won't be formalized and standadized rules for resolution, but
aren't people in this project sensible enough, in general, to have the
common sense to reach an adequate solution?

On Sat, Oct 27, 2018 at 4:10 PM Martin Smith  wrote:

> >Well, then let me give you my simple minded opinion on this topic, an
> engineers
> >opinion:
> >Do not introduce a CoC.
>
> In that case, if a contributor is mistreated by another contributor, what
> recourse does the victim have?
>
> martin
>
> 
> From: Development 
> on behalf of Bernhard Lindner 
> Sent: Saturday, October 27, 2018 12:39:40 AM
> To: development@qt-project.org
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> > But the only mailing list with sufficient representation of the
> community is
> > this one. We don't have to like discussing this, but it seems necessary
> that
> > we do.
>
> Well, then let me give you my simple minded opinion on this topic, an
> engineers opinion:
> Do not introduce a CoC.
>
> Resisting to have anything and everything in black and white is hard and
> is not popular
> and surely not zeitgeist but sometimes the better way.
>
> Please do not make me discuss about that as well, I prefer to wrangle with
> item delegate
> code ;)
>
> --
> Best regards,
> Bernhard Lindner
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Martin Smith]

>Well, then let me give you my simple minded opinion on this topic, an engineers
>opinion:
>Do not introduce a CoC.

In that case, if a contributor is mistreated by another contributor, what 
recourse does the victim have?

martin


From: Development  on 
behalf of Bernhard Lindner 
Sent: Saturday, October 27, 2018 12:39:40 AM
To: development@qt-project.org
Subject: Re: [Development] QUIP 12: Code of Conduct

> But the only mailing list with sufficient representation of the community is
> this one. We don't have to like discussing this, but it seems necessary that
> we do.

Well, then let me give you my simple minded opinion on this topic, an engineers 
opinion:
Do not introduce a CoC.

Resisting to have anything and everything in black and white is hard and is not 
popular
and surely not zeitgeist but sometimes the better way.

Please do not make me discuss about that as well, I prefer to wrangle with item 
delegate
code ;)

--
Best regards,
Bernhard Lindner

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

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[Kevin Kofler]

Elvis Stansvik wrote:
> Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart :
>> Jokes aside, I think we still should let users use Q_FOREACH for
>> implicitly shared containers.
> 
> Yes, I thought that Q_FOREACH was slated for deprecation though. But
> maybe that's not set in stone yet?

That's his point, it should be undeprecated.

Kevin Kofler

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

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[Elvis Stansvik]

Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart :
>
> On 10/26/18 10:26 PM, Elvis Stansvik wrote:
> > For completely other reasons, I came across "Range-based for
> > statements with initializer" today:
> >
> >  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0614r1.html
> >
> > With that, the Qt best practice could become
> >
> > for (const auto list = getQList(); const auto  : list) {
> >  ...
> > }
> >
> > Which may or may not be pretty, but avoids the extra line of code and
> > keeps the scope clean.
> >
>
> We could even wrap this in a macro for convenience. We would call that macro
> 'foreach' for example.
> Ah no, wait, this name is already taken by a macro that does exactly that :-)

:)

>
> Jokes aside, I think we still should let users use Q_FOREACH for implicitly
> shared containers.

Yes, I thought that Q_FOREACH was slated for deprecation though. But
maybe that's not set in stone yet?

I just found this post by Marc: https://www.kdab.com/goodbye-q_foreach/

Lots of comments there I haven't had time to go through yet, so I bet
it's a contentious issue :)

Elvis

>
> --
> Olivier
>
> Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

[Olivier Goffart]

On 10/26/18 10:26 PM, Elvis Stansvik wrote:

For completely other reasons, I came across "Range-based for
statements with initializer" today:

 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0614r1.html

With that, the Qt best practice could become

for (const auto list = getQList(); const auto  : list) {
 ...
}

Which may or may not be pretty, but avoids the extra line of code and
keeps the scope clean.



We could even wrap this in a macro for convenience. We would call that macro 
'foreach' for example.

Ah no, wait, this name is already taken by a macro that does exactly that :-)

Jokes aside, I think we still should let users use Q_FOREACH for implicitly 
shared containers.


--
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] There are staged stuff in the CI for now close to 20 hours

[Simon Hausmann]

Indeed, the CI appears to be down as a whole. There is one single change in 
integrating state and that since yesterday, so it’s certainly not processing.

Simon

> On 27. Oct 2018, at 07:53, Thiago Macieira  wrote:
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development