[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