Just a friendly reminder about using arrays in boolean conditions

[Jonathan M Davis]

On Sunday, November 17, 2024 9:47:39 AM MST Nick Treleaven via Digitalmars-d 
wrote:
> On Sunday, 17 November 2024 at 08:57:35 UTC, Jonathan M Davis
>
> wrote:
> > Personally, I'd love to see using arrays in boolean conditions
> > simply be deprecated and then made an error (and maybe changed
> > to check for empty at some point in the future if we want to),
> > since it's often used incorrectly, and even when it is used
> > correctly, it's pretty much always a good idea to do an
> > explicit check instead of an implicit one so that it's clear to
> > anyone else reading the code what you meant to check for.
>
> It was deprecated and then un-deprecated - see
> https://issues.dlang.org/show_bug.cgi?id=4733#c38 for why it was
> problematic, possible solutions and also a link to a 2015
> discussion.

That doesn't really surprise me, and I'm not sure that the situation is
really gonig to be fixed at some point, but IMHO, as things stand, no one
should ever use an array in a boolean condition, because it's almost always
doing the wrong thing, it's not clear whether the programmer actually knew
that they were testing for non-null instead of empty, and really, no one
should be testing arrays for null outside of some cases where you're taking
the ptr value and passing it to C/C++ (and that code can just check the ptr
itself). Trying to distinguish between null arrays and empty arrays is just
too bug-prone. But as much as D improves on C/C++, we've made our own share
of mistakes in the design of D.

Honestly, if we could change things without caring about backwards
compatibility, I'd get rid of null arrays entirely - not get rid of having
the ptr field for arrays be null, since that's obviously desirable, but get
rid of the symbol null interacting with arrays themselves and the concept
that an array itself could be null. The way that D's arrays work allows us
to not worry about whether arrays are null (whereas languages where arrays
are pointers or classes definitely have to worry about it), but we didn't
take it quite far enough, likely at least in part because of how much Walter
was used to thinking about arrays as being a pointer thanks to C/C++ when he
came up with D dynamic arrays.

So, ideally, you wouldn't be able to initialize arrays with null (you'd need
to use [] instead), null wouldn't convert to arrays at all, and it wouldn't
be comparable with arrays at all. And then boolean conditions would check
for non-empty rather than non-null. The whole mess would be cleaner that
way, because then it would be entirely clear that it's empty that matters,
not null, and we wouldn't have people trying to treat null arrays as special
or get any of the confusion that we currently get with null vs empty. The
edge cases where null is treated as special for arrays by either the
language or by programmers is just error-prone, and the lower level code
that needs to care whether the ptr itself is null would still be able to do
that.

However, given how much null currently gets used with arrays, we could never
make that change at this point. We might be able to change how arrays
interact with boolean conditions to at least improve the situation, but
that's probably as far as we'd be able to go even with editions.

- Jonathan M Davis