[Development] Fwd: RFF: nullptr rules

[Richard Moore]

Resending from the right address.

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




On 9 December 2015 at 15:14, Marc Mutz <marc.mutz at kdab.com> 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.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20151209/ca414f33/attachment.html>