Resending from the right address.

---------- Forwarded message ----------
From: Richard Moore <[email protected]>
Date: 9 December 2015 at 17:22
Subject: Re: [Development] RFF: nullptr rules
To: "[email protected]" <[email protected]>




On 9 December 2015 at 15:14, Marc Mutz <[email protected]> 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
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to