Paul Eggert wrote:
> > The diffutils patch shows that the possible bugs had already been caught
>
> Sure, but the idea is to make such bugs less likely in the future, by
> encouraging the use of nullptr now.
The gain here is small (it's only varargs and contrived cases), whereas ...
> > 2) We should avoid gratuitous style differences between code in Gnulib and
> > general coding habits in the community, because that increases the barrier
> > to entry and confuses newcomers.
>
> This barrier is so small as to not be worth worrying about.
I disagree here. Ignoring or underestimating the "barrier to entry" issue
was my biggest mistake in GNU clisp development so far. Even such simple
things tend to turn contributors off.
> People
> accustomed to NULL can still submit patches containing NULL, and we can
> accept them.
This would be even worse, because it would lead to a random mix of code
with NULL and code with nullptr. Each time programmers have the choice
between two equivalent ways of coding something, it has three negative
effects:
* They spend time reflecting whether they should use one or the other.
Since the two are equivalent, this is wasted time.
* They get attached to doing it one way, developing a personal style.
And then they change past contributions by other developers, because
they get annoyed or even angry about the other style.
* When searching for some code by pattern or idiom, a developer may
need two 'grep' runs instead of one.
We've seen this happen
- with the indentation width and braces style, before the GCS were
invented,
- with spaces indentation vs. mixed tab/spaces indentation,
- in Common Lisp, with SETQ vs. SETF,
- in C++, with many other constructs. Last time I counted, there were
12 different ways to define a function in C++. And the programmers
spend a lot of time deliberating which of them to choose in each
particular situation. What a waste of time!
Thus, it is better to have a rule (at least per project). Any of the
two rules
- "Avoid NULL, write nullptr always."
- "In varargs calls, write nullptr instead of (foo *) NULL."
is better than a random mix of NULL and nullptr in the same project.
Bruno
