[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