Re: [Development] Qt 5.7 feature freeze postponed, new date to be agreed

[Turunen Tuukka]

Hi,

A blog post is in the works, but not yet published. Now we have been focusing 
to get the Qt 5.6 beta out.

We have not changed how Qt is built, codereview or the HW of CI, it is only the 
CI SW side that is renewed.

Yours,

--
Tuukka

"m...@rpzdesign.com" 
mailto:m...@rpzdesign.com>> kirjoitti 9.12.2015 kello 19.46:

Tuuka:

I was looking around for "Coin CI" information on google.

Can you provide links and additional insight into this CI?

We have a thread on the interest list related to CI.

md


On 12/9/2015 9:58 AM, Turunen Tuukka wrote:

Hi,

15th Jan sounds good to me as the new FF time for Qt 5.7. The idea is to have 
the currently TP modules (at least many of them) supported with Qt 5.7 and also 
to drop the non-C++11 compilers as already discussed, agreed and implemented 
for dev. Therefore the content of Qt 5.7 is to a large extent already shaping 
up and in case someone has new features just starting, these are probably 
better to aim towards Qt 5.8. I really would like us the finally get to the 
desired April & October release cycle during 2016 with the new Coin CI. Even 
though moving Qt 5.7 FF to 15th Jan means the final being in May instead of 
April, I think it is something we can accept.

Yours,

  Tuukka

From: Development [mailto:development-boun...@qt-project.org] On Behalf Of 
Heikkinen Jani
Sent: keskiviikkona 9. joulukuuta 2015 12.22
To: development@qt-project.org
Subject: [Development] Qt 5.7 feature freeze postponed, new date to be agreed
Importance: High


Hi all,



According to original plans we should have Qt 5.7 FF next Friday (18th Dec). 
But we are still fighting to get Qt 5.6 (beta) out so there is no point to 
start freezing Qt 5.7 yet. We discussed about that yesterday's release team 
meeting & agreed to start discussion in ML about the issue. Ideally we should 
wait Qt 5.6.0 RC before start freezing Qt 5.7. But waiting Qt 5.6.0 RC might 
cause unnecessary delay for Qt 5.7 as well and I don't want to postpone 5.7 so 
much. That's why I propose 15th Jan 2016 for new feature freeze date for Qt 
5.7. It should be quite near Qt 5.6.0 RC (if we managed to get Qt 5.6.0 out 
during next week as planned).



br,
Jani



___
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] toLower() vs. toCaseFolded()

[deDietrich Gabriel]

On Dec 9, 2015, at 1:27 PM, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

For example, when title-casing in French, you drop accents ("école" becomes 
"Ecole").

This is off-topic but no, you don’t. Please, stop propagating this.

This is a common mistake introduced mostly during the typewriter era and 
perpetuated by the (obvious, in my opinion) inadequacy of the AZERTY keyboard 
layout and input methods for writing French. The Académie française is 
unambiguously clear about accents on capital letters as are all serious French 
typography guides.

Mandatory Wikipedia link: 
https://fr.wikipedia.org/wiki/Usage_des_majuscules_en_français#Accentuation_des_majuscules_et_des_capitales
 (actually, the English article is a bit more explicit about the current state 
of confusion https://en.wikipedia.org/wiki/Capitalization#Accents).

Best regards,

Dr. Gabriel de Dietrich
Senior Software Developer
The Qt Company — www.qt.io

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

Re: [Development] RFF: nullptr rules

[Thiago Macieira]

On Wednesday 09 December 2015 17:41:26 Matthew Woehlke wrote:
> On 2015-12-09 17:29, Thiago Macieira wrote:
> > On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote:
> > 
> > I'd like to propose this:
> >  [...]
> >  c) which means no -Werror=zero-as-nullptr outside of headersclean
> 
> I just want to say that I think this is fair. The key phrase there is
> "outside of". -Wzero-as-nullptr is controversial and I can totally
> understand and accept the Qt project not wanting to go there. It's the
> *public* headers that (potentially) spill over into preventing other
> projects that use Qt from choosing to use -W[error=]zero-as-nullptr
> themselves. So only enforcing it there is more than sufficient to
> satisfy external consumers of Qt.

For headersclean, we can already enable for 5.6.

-- 
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] RFF: nullptr rules

[Matthew Woehlke]

On 2015-12-09 17:29, Thiago Macieira wrote:
> On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote:
> I'd like to propose this:
>  [...]
>  c) which means no -Werror=zero-as-nullptr outside of headersclean

I just want to say that I think this is fair. The key phrase there is
"outside of". -Wzero-as-nullptr is controversial and I can totally
understand and accept the Qt project not wanting to go there. It's the
*public* headers that (potentially) spill over into preventing other
projects that use Qt from choosing to use -W[error=]zero-as-nullptr
themselves. So only enforcing it there is more than sufficient to
satisfy external consumers of Qt.

(Also; thanks for thinking of said consumers!)

-- 
Matthew

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

Re: [Development] RFF: nullptr rules

[Thiago Macieira]

On Wednesday 09 December 2015 22:54:22 Marc Mutz wrote:
> Whatever happened to KISS?

That's a good reason not to run clang-modernize and force people to review.

-- 
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] RFF: nullptr rules

[Thiago Macieira]

On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote:
> > const char *ptr = 0;
> 
> What we agreed on was for Q_NULLPTR.
> 
> Some developers back then were complaining that the *macro* is ugly, and
> that by 5.7, we would be able to use the real thing and didn't want the
> double conversion 0 -> Q_NULLPTR -> nullptr.
> 
> The agreement back then also was not to rely on the disambiguating features
> of nullptr, because Q_NULLPTR might be 0.
> 
> Now we can use the real thing. With real nullptr semantics.

True.

I'd like to propose this:
 a) no massive replacement or clang-modernize, for the reasons Richard pointed 
out
 b) which means existing zeroes continue in sources and private headers
 c) which means no -Werror=zero-as-nullptr outside of headersclean

New code should use nullptr where it improves readability.

Changes to existing code can update to use nullptr.

But I don't think we should mandate use of nullptr everywhere. Where it's 
unambiguous, it doesn't add value.

-- 
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] toLower() vs. toCaseFolded()

[Thiago Macieira]

On Wednesday 09 December 2015 22:56:48 Marc Mutz wrote:
> On Wednesday 09 December 2015 11:54:54 Marc Mutz wrote:
> > Can someone please tell me the difference and why toCaseFolded() exists in
> > the  first place? Is it faster? Is it guaranteed to not make the string
> > longer/shorter?
> 
> To be more precise: I'd like the docs to say when I should use
> toCaseFolded() or toLower(). Since the Unicode docs linked say
> toCaseFolded() is locale- dependent, as an API user I'd also wonder which
> locale the QString function uses.

QString is *not* locale dependent and must not be. toCaseFolding does not 
imply that. We have no code for doing Turkic (Turkish and Azerbaijani) case 
mapping of i/İ/ı/I along with i̇/İ.

We could add overloads to the case mapping functions that take an extra enum 
indicating whether to do the "T" mapping and we should add QLocale overloads 
too that enable it automatically depending on locale.

Another alternative is to add a new class that does locale-specific case 
mapping, along with natural sorting. For example, when title-casing in French, 
you drop accents ("école" becomes "Ecole"). Assuming such data exists and is 
implemented in ICU.

-- 
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] toLower() vs. toCaseFolded()

[Marc Mutz]

On Wednesday 09 December 2015 11:54:54 Marc Mutz wrote:
> Can someone please tell me the difference and why toCaseFolded() exists in
> the  first place? Is it faster? Is it guaranteed to not make the string
> longer/shorter?

To be more precise: I'd like the docs to say when I should use toCaseFolded() 
or toLower(). Since the Unicode docs linked say toCaseFolded() is locale-
dependent, as an API user I'd also wonder which locale the QString function 
uses.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFF: nullptr rules

[Marc Mutz]

On Wednesday 09 December 2015 16:14:00 Marc Mutz wrote:
> Hi,
> 
> in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler,
> but there are no guidelines as to its use in the coding conventions (to
> the extent they need to be in there).
> 
> I propose the following, based on Thiago's proposal from January this year,
> considering the new situation that we now require nullptr support in the
> compiler:
> 
> - 0 as a nullptr constant is banned except in tests testing APIs so
>   we don't accidentally require nullptr (ie. all tests should use 0, not
>   nullptr, as far as it makes sense)
> - clang-modernize is used to convert all uses of the null pointer constant
> to nullptr, incl. examples, excl. tests and 3rdparty
> - compilers that have it, will have -Wzero-as-nullptr-constant added during
>   headersclean[0]
> - APIs that require the use of nullptr for disambiguation are discouraged,
>   but may be acceptable to be decided on a case-by-case basis.
> - Accidental (ie. non-apidox'ed) reliance on nullptr for disambiguation is
>   always an error. To this end, tests should continue to use 0, not
> nullptr. - if (!foo) vs. if (foo == nullptr), if (foo) vs. if (foo !=
> nullptr): author's prerogative[1]
> 
> [0] I'd prefer "when building Qt", but realise that we'll have problems
> with upstream libs
> [1] I prefer the short form, but I don't think we'll gain a consensus here,
> so let's not even try
> 
> Arguments in favour:
> - it's the C++ way of writing the null pointer constant these days
> - we need to use it in headers, anyway, to allow people to use
> -Wzero-as..., and it makes no sense to have two sets of rules for headers
> and impl - it can disambiguate code and prevent accidents
> - in some situations, it makes code easier to understand (:
> m_foo(nullptr)).
> 
> Arguments against:
> - it's uglier than "0", and more to type

Because it's coming up again to have nullptr only in some places and leave 0 
in others:

The predictable "let's use it only in X" reply is a rearguard battle trying to 
keep the _inevitable_ change from 0 to nullptr contained to a certain subset 
of cases, thereby complicating the ruleset, subsequently the reviews based on 
that ruleset and thwards automatic migration.

Converting _all_ null pointer constants to nullptr is a simple run of clang-
modernize. It is reasonable to trust the tool and not review every single 
instance by multiple people on Gerrit, but wave it though into CI quickly.

But if we have a complicated ruleset for when to use nullptr and when to use 
0, the person submitting the results of clang-modernize will have to wade 
through the changes one-by-one, separating the wanted from the unwanted 
changes. Then a few Gerrit reviewers will have to review all the changes 
_again_, matching against the ruleset, discussing unclear situations

All this just because some people have an aesthetic problem with "nullptr". 
Guess what, you can always s/nullptr/0/ for display, but the converse is _not_ 
possible.

Whatever happened to KISS?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFF: nullptr rules

[Marc Mutz]

On Wednesday 09 December 2015 19:11:29 Thiago Macieira wrote:
> On Wednesday 09 December 2015 16:14:00 Marc Mutz wrote:
> > - 0 as a nullptr constant is banned except in tests testing APIs so
> >
> >   we don't accidentally require nullptr (ie. all tests should use 0, not
> >   nullptr, as far as it makes sense)
> 
> This is not what we had agreed to.
> 
> We had said that where it's unambiguous, we can still use 0, outside of
> public  headers.
> 
> const char *ptr = 0;

What we agreed on was for Q_NULLPTR.

Some developers back then were complaining that the *macro* is ugly, and that 
by 5.7, we would be able to use the real thing and didn't want the double 
conversion 0 -> Q_NULLPTR -> nullptr.

The agreement back then also was not to rely on the disambiguating features of 
nullptr, because Q_NULLPTR might be 0.

Now we can use the real thing. With real nullptr semantics.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFF: nullptr rules

[Thiago Macieira]

On Wednesday 09 December 2015 16:14:00 Marc Mutz wrote:
> - 0 as a nullptr constant is banned except in tests testing APIs so
>   we don't accidentally require nullptr (ie. all tests should use 0, not
>   nullptr, as far as it makes sense)

This is not what we had agreed to.

We had said that where it's unambiguous, we can still use 0, outside of public 
headers.

const char *ptr = 0;

-- 
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] toLower() vs. toCaseFolded()

[Thiago Macieira]

On Wednesday 09 December 2015 11:54:54 Marc Mutz wrote:
> Hi,
> 
> http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what case
> folding actually _is_ and how it's different from toLower().
> 
> Can someone please tell me the difference and why toCaseFolded() exists in
> the first place? Is it faster? Is it guaranteed to not make the string
> longer/shorter?

It's a different form of case transformation in Unicode. If you care about it, 
you've probably read some document that said that you should do case folding. 
An example is the "stringprep" / "nameprep" step of Internationalised Domain 
Names: it requires case folding.

It's given in the Unicode file CaseFolding.txt.

For example, İ lowercases to i, but casefolds to i + combining dot above.

Also, don't confuse case folding with title-casing. That's the difference 
between LJ, Lj, and lj and is found in the third column of cases (last column) in 
UnicodeData.txt.

01C7;LATIN CAPITAL LETTER LJ;Lu;0;L; 004C 004AN;LATIN CAPITAL 
LETTER L J;;;01C9;01C8
01C8;LATIN CAPITAL LETTER L WITH SMALL LETTER J;Lt;0;L; 004C 
006AN;LATIN LETTER CAPITAL L SMALL J;;01C7;01C9;01C8
01C9;LATIN SMALL LETTER LJ;Ll;0;L; 006C 006AN;LATIN SMALL LETTER L 
J;;01C7;;01C8


> Preferably answer by updating the docs to be a bit more descriptive.

I'd like Konstantin to do that, as he might have a better idea than "Unicode 
says so"...

-- 
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] Fwd: RFF: nullptr rules

[Matthew Woehlke]

On 2015-12-09 12:23, Richard Moore wrote:
> On 9 December 2015 at 15:14, Marc Mutz wrote:
>> Arguments in favour:
>> -Wzero-as...,
>>   and it makes no sense to have two sets of rules for headers and impl
> 
> ​There's nothing that says we need to allow people to use that warning,

...except that it isn't just a question of whether Qt uses it
internally, it affects whether or not *consumers* (of Qt) can use it.

(And yes, there is some extent to which this is a compiler problem, but
fixing it in the compiler is apparently really, really difficult. See
e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486.)

> and nothing stopping us disabling it for our headers,

...except when that doesn't work, e.g. the bug report Marc referenced.

-- 
Matthew

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

Re: [Development] Qt 5.7 feature freeze postponed, new date to be agreed

[m...@rpzdesign.com]

Tuuka:

I was looking around for "Coin CI" information on google.

Can you provide links and additional insight into this CI?

We have a thread on the interest list related to CI.

md


On 12/9/2015 9:58 AM, Turunen Tuukka wrote:


Hi,

15th Jan sounds good to me as the new FF time for Qt 5.7. The idea is 
to have the currently TP modules (at least many of them) supported 
with Qt 5.7 and also to drop the non-C++11 compilers as already 
discussed, agreed and implemented for dev. Therefore the content of Qt 
5.7 is to a large extent already shaping up and in case someone has 
new features just starting, these are probably better to aim towards 
Qt 5.8. I really would like us the finally get to the desired April & 
October release cycle during 2016 with the new Coin CI. Even though 
moving Qt 5.7 FF to 15^th Jan means the final being in May instead of 
April, I think it is something we can accept.


Yours,

  Tuukka

*From:*Development [mailto:development-boun...@qt-project.org] *On 
Behalf Of *Heikkinen Jani

*Sent:* keskiviikkona 9. joulukuuta 2015 12.22
*To:* development@qt-project.org
*Subject:* [Development] Qt 5.7 feature freeze postponed, new date to 
be agreed

*Importance:* High

Hi all,

According to original plans we should have Qt 5.7 FF next Friday (18th 
Dec). But we are still fighting to get Qt 5.6 (beta) out so there is 
no point to start freezing Qt 5.7 yet. We discussed about that 
yesterday's release team meeting & agreed to start discussion in ML 
about the issue. Ideally we should wait Qt 5.6.0 RC before start 
freezing Qt 5.7. But waiting Qt 5.6.0 RC might cause unnecessary delay 
for Qt 5.7 as well and I don't want to postpone 5.7 so much. That's 
why I propose 15th Jan 2016 for new feature freeze date for Qt 5.7. It 
should be quite near Qt 5.6.0 RC (if we managed to get Qt 5.6.0 out 
during next week as planned).


br,

Jani



___
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] Fwd: RFF: nullptr rules

[Marc Mutz]

On Wednesday 09 December 2015 18:23:20 Richard Moore wrote:
> > Arguments in favour:
[...]
> > -Wzero-as...,
> >
> >   and it makes no sense to have two sets of rules for headers and impl
> 
> ​There's nothing that says we need to allow people to use that warning, and
> nothing stopping us disabling it for our headers, so this is a
> non-argument.​

https://bugreports.qt.io/browse/QTBUG-45291

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFF: nullptr rules

[Marc Mutz]

On Wednesday 09 December 2015 16:38:02 Joerg Bornemann wrote:
> > - if (!foo) vs. if (foo == nullptr), if (foo) vs. if (foo != nullptr):
> >author's prerogative[1]
[...]
> > [1] I prefer the short form, but I don't think we'll gain a consensus
> > here, so let's not even try
> 
> So why do you try yet?

What part of "author's prerogative" was unclear?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFF: nullptr rules

[Marc Mutz]

On Wednesday 09 December 2015 16:19:38 Matthew Woehlke wrote:
> > - APIs that require the use of nullptr for disambiguation are
> > discouraged,
> >
> >   but may be acceptable to be decided on a case-by-case basis.
> 
> On that note, there is one case in which '0' as nullptr makes sense...
> default values for QFlags. A literal '0' "looks like" an empty bitset
> much more than 'nullptr', even though IIRC it actually ends up
> implemented via a void* ctor. This probably means that those should be
> changed to use '{}' as the default initializer instead (i.e. not
> 'nullptr'). I'm not sure what this means for compiler support (i.e. if
> any compilers that Qt still supports don't support it), though I do know
> offhand it does exclude GCC < 4.7.
> 
> (Alternatively, there could be a qNullFlag or some such, but that might
> have compatibility problems.)

FTR: this is already fixed in QtBase 5.6, but not other modules, by using the 
default ctor (uniform init isn't required in Qt 5.7).

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Marc Mutz]

On Wednesday 09 December 2015 16:02:01 Matthew Woehlke wrote:
> Especially if there ever does end up being code in Qt
> operating on STL objects where the correct type is something esoteric
> like 'std::vector::size_type'.

Already there: qmetaobjectbuilder.cpp

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Marc Mutz]

On Wednesday 09 December 2015 15:52:04 Rolland Dudemaine wrote:
> If I may ask, what is wrong with not using features of a language?

Nothing. Except that new generations of programmers will look at the code 
written in 90s style, label it "legacy", treat it with utmost disgust, slow 
down to a crwawl when making changes to it and demand 150% of the rates when 
going in.

This whole story of "code is written once, and read many times" is wrong (the 
"once" part). Code should be continuously evolved to stay current. Just try 
compiling Qt 3.x with a current GCC and you will know why.

> I've always been a fan of Qt, not because of its conciseness,
> portability, versatility (although these help), but really because a C++
> beginner, a seasoned C engineer unfamiliar with C++, and several other
> non-expert types can read and understand the Qt API, and also write
> basic applications.
> 
> Preaching pragmatism, I'd happily vote for "what's convenient" inside
> the Qt implementation, but also vote against the C++11-ification of the
> API.

This discussion is not about the Qt API. It is about its implementation.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Fwd: RFF: nullptr rules

[Richard Moore]

Resending from the right address.

-- Forwarded message --
From: Richard Moore 
Date: 9 December 2015 at 17:22
Subject: Re: [Development] RFF: nullptr rules
To: "development@qt-project.org" 




On 9 December 2015 at 15:14, Marc Mutz  wrote:

> - 0 as a nullptr constant is banned except in tests testing APIs so
>   we don't accidentally require nullptr (ie. all tests should use 0, not
>   nullptr, as far as it makes sense)
>

​This seems pretty arbitrary to me, and would lead to inconsistency with
APIs that ​predated this rule. I can't say I'm in favour.



> - clang-modernize is used to convert all uses of the null pointer constant
> to
>   nullptr, incl. examples, excl. tests and 3rdparty
>

​Won't this just add noise and make forward porting bug fixes harder? I
don't see it gains much.​


> - APIs that require the use of nullptr for disambiguation are discouraged,
>   but may be acceptable to be decided on a case-by-case basis.
>

​Makes sense​


>
> Arguments in favour:
> - it's the C++ way of writing the null pointer constant these days
> - we need to use it in headers, anyway, to allow people to use
> -Wzero-as...,
>   and it makes no sense to have two sets of rules for headers and impl
>

​There's nothing that says we need to allow people to use that warning, and
nothing stopping us disabling it for our headers, so this is a
non-argument.​


> - it can disambiguate code and prevent accidents
>

​I'm not convinced about this for sane APIs.​


> - in some situations, it makes code easier to understand (:
> m_foo(nullptr)).
>
>
I don't see any difference from 0 here to be honest, but perhaps that's
just me.​


> Arguments against:
> - it's uglier than "0", and more to type
>

​Definitely, also:​


- ​It will also make forward-porting​

​bug fixes and merges harder.​

- If the automated change you suggest was done then the history would be (a
little) less useful.

​Cheers

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

Re: [Development] RFF: nullptr rules

[Mathias Hasselmann]

Am 09.12.2015 um 16:14 schrieb Marc Mutz:


Arguments in favour:
- it's the C++ way of writing the null pointer constant these days
- we need to use it in headers, anyway, to allow people to use -Wzero-as...,
   and it makes no sense to have two sets of rules for headers and impl
- it can disambiguate code and prevent accidents
- in some situations, it makes code easier to understand (: m_foo(nullptr)).

Arguments against:
- it's uglier than "0", and more to type


Have we discussed "{}" instead of "nullptr", or "0" already?

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

Re: [Development] toLower() vs. toCaseFolded()

[Mathias Hasselmann]

Am 09.12.2015 um 12:20 schrieb Marc Mutz:

On Wednesday 09 December 2015 10:57:21 Florian Bruhin wrote:

* Marc Mutz  [2015-12-09 11:54:54 +0100]:

Hi,

http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what
case folding actually _is_ and how it's different from toLower().

Can someone please tell me the difference and why toCaseFolded() exists
in the first place? Is it faster? Is it guaranteed to not make the
string longer/shorter?


Maybe http://www.w3.org/International/wiki/Case_folding helps?


Not really. Neither does it patch our docs... :)

Like that W3C document says the difference really is about handling of 
characters like ß, or the different variants of I in Turkic languages. 
While doing word prediction one really wants to treat words like 
"Straße", "STRASSE" to be equal and delegate the final string matching

to the user.

Details are in http://www.unicode.org/Public/8.0.0/ucd/CaseFolding.txt, 
the rows with status field other than "C" are the interesting ones.


No, this also doesn't update the docs yet.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.7 feature freeze postponed, new date to be agreed

[Turunen Tuukka]

Hi,

15th Jan sounds good to me as the new FF time for Qt 5.7. The idea is to have 
the currently TP modules (at least many of them) supported with Qt 5.7 and also 
to drop the non-C++11 compilers as already discussed, agreed and implemented 
for dev. Therefore the content of Qt 5.7 is to a large extent already shaping 
up and in case someone has new features just starting, these are probably 
better to aim towards Qt 5.8. I really would like us the finally get to the 
desired April & October release cycle during 2016 with the new Coin CI. Even 
though moving Qt 5.7 FF to 15th Jan means the final being in May instead of 
April, I think it is something we can accept.

Yours,

  Tuukka

From: Development [mailto:development-boun...@qt-project.org] On Behalf Of 
Heikkinen Jani
Sent: keskiviikkona 9. joulukuuta 2015 12.22
To: development@qt-project.org
Subject: [Development] Qt 5.7 feature freeze postponed, new date to be agreed
Importance: High


Hi all,



According to original plans we should have Qt 5.7 FF next Friday (18th Dec). 
But we are still fighting to get Qt 5.6 (beta) out so there is no point to 
start freezing Qt 5.7 yet. We discussed about that yesterday's release team 
meeting & agreed to start discussion in ML about the issue. Ideally we should 
wait Qt 5.6.0 RC before start freezing Qt 5.7. But waiting Qt 5.6.0 RC might 
cause unnecessary delay for Qt 5.7 as well and I don't want to postpone 5.7 so 
much. That's why I propose 15th Jan 2016 for new feature freeze date for Qt 
5.7. It should be quite near Qt 5.6.0 RC (if we managed to get Qt 5.6.0 out 
during next week as planned).



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

Re: [Development] RFF: nullptr rules

[Joerg Bornemann]

On 09-Dec-15 16:14, Marc Mutz wrote:


in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, but
there are no guidelines as to its use in the coding conventions (to the extent
they need to be in there).


There are also no guidelines for every other language feature, and I 
doubt that we need those. Everything that's not controlled by rules is 
controlled by common sense, which I trust this community has.



I propose the following, based on Thiago's proposal from January this year,
considering the new situation that we now require nullptr support in the
compiler:

- 0 as a nullptr constant is banned except in tests testing APIs so
   we don't accidentally require nullptr (ie. all tests should use 0, not
   nullptr, as far as it makes sense)


What is the advantage apart from fixing the edge case of having
void foo(int)
and
void foo(Blubb *)
?


- clang-modernize is used to convert all uses of the null pointer constant to
   nullptr, incl. examples, excl. tests and 3rdparty


This just adds pointless noise to the history. I see no value in it.


- compilers that have it, will have -Wzero-as-nullptr-constant added during
   headersclean[0]


I can see value in enforcing nullptr in public headers.


- APIs that require the use of nullptr for disambiguation are discouraged,
   but may be acceptable to be decided on a case-by-case basis.


I agree.


- Accidental (ie. non-apidox'ed) reliance on nullptr for disambiguation is
   always an error. To this end, tests should continue to use 0, not nullptr.
- if (!foo) vs. if (foo == nullptr), if (foo) vs. if (foo != nullptr):
   author's prerogative[1]

[0] I'd prefer "when building Qt", but realise that we'll have problems with
upstream libs
[1] I prefer the short form, but I don't think we'll gain a consensus here, so
let's not even try


So why do you try yet?


Arguments in favour:
- it's the C++ way of writing the null pointer constant these days
- we need to use it in headers, anyway, to allow people to use -Wzero-as...,
   and it makes no sense to have two sets of rules for headers and impl
- it can disambiguate code and prevent accidents


Yes, it can. In edge cases. Let's use nullptr for those.


- in some situations, it makes code easier to understand (: m_foo(nullptr)).


So nullptr is easier to understand, because assigning 0 to a pointer 
variable didn't make clear that it now contains a null pointer?
If there's need to signify using m_foo(nullptr) that m_foo is a pointer, 
then m_foo is maybe a bad name and should be fixed.


There are very few cases where nullptr actually prevents errors. Let's 
use it there. And if you think it's pretty and fits your style, use it. 
But do not enforce it just because of its mere existence.



BR,

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

Re: [Development] RFF: nullptr rules

[Matthew Woehlke]

On 2015-12-09 10:14, Marc Mutz wrote:
> in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, 
> but 
> there are no guidelines as to its use in the coding conventions (to the 
> extent 
> they need to be in there).
> 
> I propose the following, based on Thiago's proposal from January this year, 
> considering the new situation that we now require nullptr support in the 
> compiler:
> [...]
> - compilers that have it, will have -Wzero-as-nullptr-constant added during
>   headersclean[0]

Yay! :-) Yes, please, for exactly the reason you gave.

> - APIs that require the use of nullptr for disambiguation are discouraged,
>   but may be acceptable to be decided on a case-by-case basis.

On that note, there *is* one case in which '0' as nullptr makes sense...
default values for QFlags. A literal '0' "looks like" an empty bitset
much more than 'nullptr', even though IIRC it actually ends up
implemented via a void* ctor. This probably means that those should be
changed to use '{}' as the default initializer instead (i.e. not
'nullptr'). I'm not sure what this means for compiler support (i.e. if
any compilers that Qt still supports don't support it), though I do know
offhand it does exclude GCC < 4.7.

(Alternatively, there could be a qNullFlag or some such, but that might
have compatibility problems.)

> Arguments against:
> - it's uglier than "0", and more to type

FWIW, I'm with Sergio here; not sure I agree about it being "uglier"...
it's certainly more obvious that 'nullptr' is... a null pointer, and not
an integer literal...

(And, likewise, I'm more sympathetic to '0' vs. 'Q_NULLPTR'. But since
that's not what we're talking about...)

-- 
Matthew

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

Re: [Development] RFF: nullptr rules

[Sergio Martins]

On Wednesday, 9 December 2015 16:14:00 WET Marc Mutz wrote:

> Arguments in favour:
> - it's the C++ way of writing the null pointer constant these days
> - we need to use it in headers, anyway, to allow people to use -Wzero-as...,
> and it makes no sense to have two sets of rules for headers and impl - it
> can disambiguate code and prevent accidents
> - in some situations, it makes code easier to understand (: m_foo(nullptr)).

Agreed.

The last point being the strongest argument IMHO, since we don't use hungarian 
notation m_foo(0)  hurts readability. 

> Arguments against:
> - it's uglier than "0", and more to type

Not agreed. This is highly subjective, for me Q_NULLPTR was uglier than 0 but 
nullptr feels just natural.


Regards,
-- 
Sérgio Martins | sergio.mart...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Matthew Woehlke]

On 2015-12-09 08:15, Bubke Marco wrote:
> Should we recommend forward(universal) references in for loops (which are 
> "const &value" for "const values"):
> 
> for (auto &&value : values)

Someone remind me; what's the benefit of this vs. 'auto const&'
(assuming that I won't be modifying 'value')?

> or
> 
> for (const auto &value : values)
> 
> to show the difference to
> 
> for (auto &value : values)

I personally prefer making everything I can 'const'. That means 'const&'
returns from functions ("forces" a copy elision), 'const' local
variables, etc.. In the case of loops like the above, if I'm not going
to modify the value, I prefer to say so. If I *am* going to modify it, I
prefer 'auto&' to a) also say so, and b) statically ensure that I *can*.

That's just my 2¢ however; I'd be interested in hearing arguments for
'auto&&'.

-- 
Matthew

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

Re: [Development] RFC: more liberal 'auto' rules?

[Matthew Woehlke]

On 2015-12-09 07:18, Knoll Lars wrote:
> For loop variables, I don’t think we should require ‘auto’. Using it
> can be the right thing to do in some cases, esp when using patterns
> like ‘for(auto item: items)’ , but when looping using integer
> indices, I still prefer ‘for (int i=...; cond; ++i)’.

For the record, while I still think 'for (auto const i :
qIndexRange(list.count()))' is better, my objection here isn't so much
to failing to mandate 'auto' in such cases as forbidding it entirely in
such cases. Especially if there ever does end up being code in Qt
operating on STL objects where the correct type is something esoteric
like 'std::vector::size_type'.

-- 
Matthew

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

Re: [Development] RFC: more liberal 'auto' rules?

[Rolland Dudemaine]

>> Are these cases something we can agree upon?
> Too little, imho. If we continue at this speed (one week for 1.5 more use-
> cases of an already-allowed feature), then we're going to be done with C++11 
> when C++22 is out.

If I may ask, what is wrong with not using features of a language?

I've always been a fan of Qt, not because of its conciseness,
portability, versatility (although these help), but really because a C++
beginner, a seasoned C engineer unfamiliar with C++, and several other
non-expert types can read and understand the Qt API, and also write
basic applications.

Preaching pragmatism, I'd happily vote for "what's convenient" inside
the Qt implementation, but also vote against the C++11-ification of the API.

Rolland

--
Rolland Dudemaine   tel direct:+33 143 143 702
Green Hills Software   tel:+33 143 143 700
4 rue de la Pierre Leveemailto:roll...@ghs.com
75011 Paris   fax: +33 143 143 707
France web: http://www.ghs.com
--


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

Re: [Development] Nominating Samuli Pippo for Approver status

[Al-Khanji Louai]

+1!

_
From: Meadows Louis 
mailto:louis.mead...@theqtcompany.com>>
Sent: Wednesday, December 2, 2015 2:01 PM
Subject: Re: [Development] Nominating Samuli Pippo for Approver status
To: mailto:development@qt-project.org>>, Agocs 
Laszlo mailto:laszlo.ag...@theqtcompany.com>>


+1 from me as well

From: Development [mailto:development-boun...@qt-project.org] On Behalf Of 
Agocs Laszlo
Sent: Wednesday, December 02, 2015 6:13 AM
To: development@qt-project.org
Subject: [Development] Nominating Samuli Pippo for Approver status


Hello,

I would like to nominate Samuli Piippo for Approver status in the Qt Project. 
Samuli has been working on Qt's Embedded Linux support and Qt for Device 
Creation during the past few years. He is our resident Yocto expert and is 
contributing to meta-qt5 as well.

Public Gerrit dashboard: 
https://codereview.qt-project.org/#/q/owner:samuli.piippo,n,z

meta-qt5 contributions: 
https://github.com/meta-qt5/meta-qt5/commits/master?author=sapiippo

Best regards,
Laszlo



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

Re: [Development] RFC: more liberal 'auto' rules?

[Marc Mutz]

On Wednesday 09 December 2015 14:15:47 Bubke Marco wrote:
> for (auto &&value : values)

This is ok in generic code.

In non-generic code, I think it's too clever.

In general, I would always try to preserve which kind of type we're dealing 
with:

   const auto *e =
   auto e* =
   const auto &e =
   auto &e =
   auto e =
   const auto e =

But that's just the level of auto that _I_ feel comfortable with. YMMV.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] RFF: nullptr rules

[Marc Mutz]

Hi,

in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, but 
there are no guidelines as to its use in the coding conventions (to the extent 
they need to be in there).

I propose the following, based on Thiago's proposal from January this year, 
considering the new situation that we now require nullptr support in the 
compiler:

- 0 as a nullptr constant is banned except in tests testing APIs so
  we don't accidentally require nullptr (ie. all tests should use 0, not
  nullptr, as far as it makes sense)
- clang-modernize is used to convert all uses of the null pointer constant to
  nullptr, incl. examples, excl. tests and 3rdparty
- compilers that have it, will have -Wzero-as-nullptr-constant added during
  headersclean[0]
- APIs that require the use of nullptr for disambiguation are discouraged,
  but may be acceptable to be decided on a case-by-case basis.
- Accidental (ie. non-apidox'ed) reliance on nullptr for disambiguation is
  always an error. To this end, tests should continue to use 0, not nullptr.
- if (!foo) vs. if (foo == nullptr), if (foo) vs. if (foo != nullptr):
  author's prerogative[1]

[0] I'd prefer "when building Qt", but realise that we'll have problems with 
upstream libs
[1] I prefer the short form, but I don't think we'll gain a consensus here, so 
let's not even try

Arguments in favour:
- it's the C++ way of writing the null pointer constant these days
- we need to use it in headers, anyway, to allow people to use -Wzero-as...,
  and it makes no sense to have two sets of rules for headers and impl
- it can disambiguate code and prevent accidents
- in some situations, it makes code easier to understand (: m_foo(nullptr)).

Arguments against:
- it's uglier than "0", and more to type

Let's have comments and additions float in for a week, and then let's have Lars 
decide.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Poenitz Andre]

Lars wrote:
> I don’t think there is a full consensus. 

Indeed, there isn't.

> Let me try to summarise where 
> we are, what I think we agree upon and then add my thoughts :)
> 
> As a primary goal, auto should be used wherever it increases readability 
> of the code. I think we all agree here. The problem is that there’s dissent
> in what ‘more readable code’ is in practice.
> 
> I think everybody also agrees one the use cases listed in 
> https://wiki.qt.io/Coding_Conventions#auto_Keyword , so the question now 
> is what additional use cases do most of us agree to? 
> 
> And how to put that into rules, as a listing with 50 entries won’t help 
> anybody.

I agree with that so far.

> While I don’t think we should go and implement aaa right now, I would 
> probably 
> be ok with a somewhat broader usage than the current coding conventions imply.

> Marc presented some use cases. Going through those, I don’t think I heard 
> any disagreement about using auto in template, so I think we can probably
> add that one to our guidelines.

Marc's proposal included to *require* use of "auto" in some cases.

I do not agree with that *required* use at all. That's not just because "auto 
is required in templates" would give the AAA supporters suddenly
a big incentive to start writing or converting normal functions to templates 
just because they can use auto freely there, but since I don't believe visible 
types are bad per-se and far less of a "problem" than the AAA faction tries 
to make me believe.

I would accept (and probably use myself) "optional use of auto" for

- *some* template code (e.g. the mentioned 'typename' case)
- references to elements in a collection *with "non-trivial" type*, i.e.
  something that is a template instance, or in deeply nested namespaces.
  (i.e. ok for  std::pair, not ok for 'int' or 'QString')

Marc's *optional* proposal "Optional use of auto: whereever it makes sense. 
Use your own judgement, but remember: fear is a bad advisor." pretty much
opens the door for AAA, as for an AAA supporter "auto" will *always* make
sense.

So effectively the proposal consists of two attempts to implement an AAA
policy. That's going way too far in one step.

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

Re: [Development] RFC: more liberal 'auto' rules?

[Marc Mutz]

On Wednesday 09 December 2015 13:18:06 Knoll Lars wrote:
> as a listing with 50 entries won’t help anybody.

Indeed. Therefore the suggestion to opt into C++ features, but optiing out of 
specific use cases. We have no indication that any compiler has problems with 
auto variables, so I don't see a reason for the Coding Style to restrict their 
use.

We don't restrict the use of other C++ feature, such as do-while loops, 
either, even though they're inherently unreadable. Why do we need detailed, 
point-by-point rules micromanging the use of auto?

The problem with codifying what isn't codifiable (due to lack of consensus in 
the wider C++ community) is that it will set in stone something that should 
grow as understanding grows. Some people are scared of auto, other (_not_ me, 
in case that wasn't clear) want to go to the other extreme: AAA-style. 
Codifying any two of the positions is wrong. Picking something in-between is 
something for people with a crystal ball.

We should _require_ a small set of use-cases, for code consistency, and leave 
the rest for comments in reviews. That only works, of course, if people don't 
start running around -2'ing code just because they think there are too many or 
too few autos in there. It should be the prerogative of the patch author to 
decide, as she's the one doing the work. It's as subjective as variable 
naming, and we also only have very broad guidelines for that.

> Are these cases something we can agree upon?

Too little, imho. If we continue at this speed (one week for 1.5 more use-
cases of an already-allowed feature), then we're going to be done with C++11 
when C++22 is out.

It's ok to discuss things, but discussions on this mailing-list tend to be 
fruitless (there's no conclusion to Thiago's thread "Upgrading the source..." 
from January 2015), tend to be hijacked by people over and over again who are 
"against" every change, the OP getting side-tracked into offside discussions 
(his fault! :), and discouragement for all sides involved.

Please just _decide_. I, for one, pledge to live with the outcome. You heard 
all the arguments. Let's get it over with, and start over with nullptr :) For 
5.8, we can re-open the discussion for auto variables.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

I would like to bring up the a case from creator:

const TextEditor::FontSettings &fontSettings = 
TextEditor::TextEditorSettings::instance()->fontS
ettings();

I really prefer in that case 

const auto &fontSettings = 
TextEditor::TextEditorSettings::instance()->fontSettings();




Should we recommend forward(universal) references in for loops (which are 
"const &value" for "const values"):

for (auto &&value : values)

or

for (const auto &value : values)

to show the difference to

for (auto &value : values)

From: Development  on behalf of Knoll Lars 

Sent: Wednesday, December 09, 2015 1:18 PM
To: Giuseppe D'Angelo
Cc: development@qt-project.org
Subject: Re: [Development] RFC: more liberal 'auto' rules?

On 09/12/15 11:19, "Giuseppe D'Angelo"  wrote:



>On Wed, Dec 9, 2015 at 11:16 AM, Knoll Lars  
>wrote:
>> And I’d say it’s about time to stop that particular sub-thread. It’s neither 
>> productive nor leading anywhere.

Just for the record here, I was only asking to stop the off topic part of the 
discussion (about python and who’s right there). Let’s focus on auto in c++ and 
how we want to use it.

>
>Is there a consensus otherwise about a more liberal use of auto in our
>source code?

I don’t think there is a full consensus. Let me try to summarise where we are, 
what I think we agree upon and then add my thoughts :)

As a primary goal, auto should be used wherever it increases readability of the 
code. I think we all agree here. The problem is that there’s dissent in what 
‘more readable code’ is in practice.

I think everybody also agrees one the use cases listed in 
https://wiki.qt.io/Coding_Conventions#auto_Keyword , so the question now is 
what additional use cases do most of us agree to? And how to put that into 
rules, as a listing with 50 entries won’t help anybody.

While I don’t think we should go and implement aaa right now, I would probably 
be ok with a somewhat broader usage than the current coding conventions imply.

Marc presented some use cases. Going through those, I don’t think I heard any 
disagreement about using auto in template, so I think we can probably add that 
one to our guidelines.

For loop variables, I don’t think we should require ‘auto’. Using it can be the 
right thing to do in some cases, esp when using patterns like ‘for(auto item: 
items)’ , but when looping using integer indices, I still prefer ‘for (int 
i=...; cond; ++i)’.

Are these cases something we can agree upon?

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] RFC: more liberal 'auto' rules?

[Knoll Lars]

On 09/12/15 11:19, "Giuseppe D'Angelo"  wrote:



>On Wed, Dec 9, 2015 at 11:16 AM, Knoll Lars  
>wrote:
>> And I’d say it’s about time to stop that particular sub-thread. It’s neither 
>> productive nor leading anywhere.

Just for the record here, I was only asking to stop the off topic part of the 
discussion (about python and who’s right there). Let’s focus on auto in c++ and 
how we want to use it.

>
>Is there a consensus otherwise about a more liberal use of auto in our
>source code?

I don’t think there is a full consensus. Let me try to summarise where we are, 
what I think we agree upon and then add my thoughts :)

As a primary goal, auto should be used wherever it increases readability of the 
code. I think we all agree here. The problem is that there’s dissent in what 
‘more readable code’ is in practice. 

I think everybody also agrees one the use cases listed in 
https://wiki.qt.io/Coding_Conventions#auto_Keyword , so the question now is 
what additional use cases do most of us agree to? And how to put that into 
rules, as a listing with 50 entries won’t help anybody.

While I don’t think we should go and implement aaa right now, I would probably 
be ok with a somewhat broader usage than the current coding conventions imply. 

Marc presented some use cases. Going through those, I don’t think I heard any 
disagreement about using auto in template, so I think we can probably add that 
one to our guidelines. 

For loop variables, I don’t think we should require ‘auto’. Using it can be the 
right thing to do in some cases, esp when using patterns like ‘for(auto item: 
items)’ , but when looping using integer indices, I still prefer ‘for (int 
i=...; cond; ++i)’. 

Are these cases something we can agree upon?

Cheers,
Lars

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

Re: [Development] buildsystem now needs to keep behaviour compatibility

[Oswald Buddenhagen]

On Wed, Dec 02, 2015 at 01:04:40PM +0100, Olivier Goffart wrote:
> On Wednesday 2. December 2015 10:17:57 Joerg Bornemann wrote:
> > We should then keep build tests for these modules in the CI.
> > Otherwise we won't notice breakages.
> 
> I agree.
> 
this is true.
but that basically defeats the whole point, which was not needing to
care about these modules any more.

now reality caught up already and it turns out that i broke webkit.
well, what i actually did, i broke bug-to-bug compatibility, which
exposed a pre-existing problem in webkit, as it usually goes.

it would be possible to revert the respective qmake change (and uglify
the surrounding code), but i don't think it's reasonable to enforce this
type of stagnation - we generally accept that code which relies on
undefined or outright broken behavior is broken by fixes.

so how do we go from there? i see several options:
- continue to drag along webkit and the other deprecated modules. the
  additional cost of actually doing that in addition to compatibility
  testing is rather low with the new CI.
- release further 5.5.x versions of these modules when necessary. i
  expect this to be a lot more effort than the first option, so it
  doesn't seem reasonable.
- simply accept that it's broken, and tell people to apply patches.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 5.7 feature freeze postponed, new date to be agreed

[Heikkinen Jani]

Hi all,


According to original plans we should have Qt 5.7 FF next Friday (18th Dec). 
But we are still fighting to get Qt 5.6 (beta) out so there is no point to 
start freezing Qt 5.7 yet. We discussed about that yesterday's release team 
meeting & agreed to start discussion in ML about the issue. Ideally we should 
wait Qt 5.6.0 RC before start freezing Qt 5.7. But waiting Qt 5.6.0 RC might 
cause unnecessary delay for Qt 5.7 as well and I don't want to postpone 5.7 so 
much. That's why I propose 15th Jan 2016 for new feature freeze date for Qt 
5.7. It should be quite near Qt 5.6.0 RC (if we managed to get Qt 5.6.0 out 
during next week as planned).


br,

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

Re: [Development] RFC: more liberal 'auto' rules?

[Giuseppe D'Angelo]

On Wed, Dec 9, 2015 at 11:16 AM, Knoll Lars  wrote:
> And I’d say it’s about time to stop that particular sub-thread. It’s neither 
> productive nor leading anywhere.

Is there a consensus otherwise about a more liberal use of auto in our
source code?

Cheers,
-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] toLower() vs. toCaseFolded()

[Florian Bruhin]

* Marc Mutz  [2015-12-09 12:20:36 +0100]:
> On Wednesday 09 December 2015 10:57:21 Florian Bruhin wrote:
> > * Marc Mutz  [2015-12-09 11:54:54 +0100]:
> > > Hi,
> > > 
> > > http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what
> > > case folding actually _is_ and how it's different from toLower().
> > > 
> > > Can someone please tell me the difference and why toCaseFolded() exists
> > > in the first place? Is it faster? Is it guaranteed to not make the
> > > string longer/shorter?
> > 
> > Maybe http://www.w3.org/International/wiki/Case_folding helps?
> 
> Not really. Neither does it patch our docs... :)

I'm going to say it - the overhead a small doc contribution really
discourages me from doing so. I'm tired of waiting[1] for reviews,
having to ping people again, and then fighting with the CI (though
that part is getting better).

Florian

[1] 
https://codereview.qt-project.org/#/q/owner:%22Florian+Bruhin+%253Cqt-project.org%2540the-compiler.org%253E%22+status:open,n,z

-- 
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
 I love long mails! | http://email.is-not-s.ms/


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

Re: [Development] toLower() vs. toCaseFolded()

[Gian Maxera]

Hello Marc,
I think the answer is into this Wikipedia page:
http://www.w3.org/International/wiki/Case_folding 


As you can notice, case folding in languages different from English can be more 
difficult than just lowering the characters.
So, I suppose (it’s only my guess), that the toLower just lower all characters 
without taking into account the correct language rules while toCaseFolded take 
into account language.

Ciao,
Gianluca.


> On 9 Dec 2015, at 11:20, Marc Mutz  wrote:
> 
> On Wednesday 09 December 2015 10:57:21 Florian Bruhin wrote:
>> * Marc Mutz  [2015-12-09 11:54:54 +0100]:
>>> Hi,
>>> 
>>> http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what
>>> case folding actually _is_ and how it's different from toLower().
>>> 
>>> Can someone please tell me the difference and why toCaseFolded() exists
>>> in the first place? Is it faster? Is it guaranteed to not make the
>>> string longer/shorter?
>> 
>> Maybe http://www.w3.org/International/wiki/Case_folding helps?
> 
> Not really. Neither does it patch our docs... :)
> 
> -- 
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ___
> 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] RFC: more liberal 'auto' rules?

[Knoll Lars]

On 09/12/15 11:00, "Development on behalf of Oswald Buddenhagen" 
 wrote:

>On Tue, Dec 08, 2015 at 08:43:53PM +0100, Marc Mutz wrote:
>> On Tuesday 08 December 2015 15:52:06 Oswald Buddenhagen wrote:
>> > your triple emphasis that it's not necessary *anywhere* in python
>> > implied that you do indeed mean more than just locals.
>> 
>> Only for someone who chimes in on a side-line without having read the
>> thread's first mail...
>> 
>actually, it's quite reasonable to take someone by their word when they
>make such an effort to emphasize it without further qualification.
>
>> I don't *care* whether it's "var" or no keyword or JS variant or
>> _whatever_. I said it's about the omission of the _type name_.
>>
>you're still not getting it. python's property of omitting the type name
>is *inherently* linked to it being dynamic. it's *meaningless* to
>compare the two. you're essentially arguing that auto is *just* like
>QVariant because it shares some of the visible properties. how is that
>an argument for *anything*?
>
>> You deliberately misunderstand and drag this subthread on and then
>> zoom in on the first slip of mine. That's trolling at it's worst.
>> 
>i didn't misunderstand anything (deliberately or not), and didn't
>present it as such, either. all i did was pointing out that the analogy
>wasn't that apt, and that your "joke" actually backfired. *you* dragged
>it out by deciding to treat me like an idiot instead of trying to
>understand and acknowledge the point (however trivial you may find it).
>
>> > so let's state the purpose even more clearly: i'm giving you a lesson.
>> 
>> I should have known tr(Besserwisser).
>> 
>i'm sure the irony of *you* saying that is momentarily lost on you.

And I’d say it’s about time to stop that particular sub-thread. It’s neither 
productive nor leading anywhere.

Thanks,
Lars

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

Re: [Development] toLower() vs. toCaseFolded()

[Marc Mutz]

On Wednesday 09 December 2015 10:57:21 Florian Bruhin wrote:
> * Marc Mutz  [2015-12-09 11:54:54 +0100]:
> > Hi,
> > 
> > http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what
> > case folding actually _is_ and how it's different from toLower().
> > 
> > Can someone please tell me the difference and why toCaseFolded() exists
> > in the first place? Is it faster? Is it guaranteed to not make the
> > string longer/shorter?
> 
> Maybe http://www.w3.org/International/wiki/Case_folding helps?

Not really. Neither does it patch our docs... :)

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Oswald Buddenhagen]

On Tue, Dec 08, 2015 at 08:43:53PM +0100, Marc Mutz wrote:
> On Tuesday 08 December 2015 15:52:06 Oswald Buddenhagen wrote:
> > your triple emphasis that it's not necessary *anywhere* in python
> > implied that you do indeed mean more than just locals.
> 
> Only for someone who chimes in on a side-line without having read the
> thread's first mail...
> 
actually, it's quite reasonable to take someone by their word when they
make such an effort to emphasize it without further qualification.

> I don't *care* whether it's "var" or no keyword or JS variant or
> _whatever_. I said it's about the omission of the _type name_.
>
you're still not getting it. python's property of omitting the type name
is *inherently* linked to it being dynamic. it's *meaningless* to
compare the two. you're essentially arguing that auto is *just* like
QVariant because it shares some of the visible properties. how is that
an argument for *anything*?

> You deliberately misunderstand and drag this subthread on and then
> zoom in on the first slip of mine. That's trolling at it's worst.
> 
i didn't misunderstand anything (deliberately or not), and didn't
present it as such, either. all i did was pointing out that the analogy
wasn't that apt, and that your "joke" actually backfired. *you* dragged
it out by deciding to treat me like an idiot instead of trying to
understand and acknowledge the point (however trivial you may find it).

> > so let's state the purpose even more clearly: i'm giving you a lesson.
> 
> I should have known tr(Besserwisser).
> 
i'm sure the irony of *you* saying that is momentarily lost on you.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] toLower() vs. toCaseFolded()

[Florian Bruhin]

* Marc Mutz  [2015-12-09 11:54:54 +0100]:
> Hi,
> 
> http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what case 
> folding actually _is_ and how it's different from toLower().
> 
> Can someone please tell me the difference and why toCaseFolded() exists in 
> the 
> first place? Is it faster? Is it guaranteed to not make the string 
> longer/shorter?

Maybe http://www.w3.org/International/wiki/Case_folding helps?

Florian

-- 
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
 I love long mails! | http://email.is-not-s.ms/


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

[Development] toLower() vs. toCaseFolded()

[Marc Mutz]

Hi,

http://doc.qt.io/qt-5/qstring.html#toCaseFolded is very vague on what case 
folding actually _is_ and how it's different from toLower().

Can someone please tell me the difference and why toCaseFolded() exists in the 
first place? Is it faster? Is it guaranteed to not make the string 
longer/shorter?

Preferably answer by updating the docs to be a bit more descriptive.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development