Just a friendly reminder with regards to arrays and using them in if conditions, assertions, etc. - the language unfortunately checks that they're non-null - like pointers - rather than non-empty like many people seem to expect.

I just had to fix a bug at work that was caused by someone using strings in
boolean conditions where the code was clearly supposed to be checking for
empty strings - e.g `if(!str)` and `str ? result1 : result2`
- and it broke when some code started giving it empty strings instead of
null strings.

>From what I've seen in discussions on this in the past, many people
misunderstand how this works and think that using arrays as boolean conditions checks for non-empty when in fact it checks whether the ptr field is non-null. This matches the behavior for pointers but is almost never what you actually want to do with arrays, because it's almost never a good idea to distinguish between null arrays and empty arrays, since it's quite error-prone (e.g. `"".idup is null` is true). And to make matters worse, because it's so frequently misunderstood, even if you do have a use case where it makes sense to check for non-null, it's almost never a good idea to do it implicitly instead of using !is null simply because without being explicit about it, there's pretty much no way that anyone else reading the code is going to know that the author actually meant to check for non-null instead of misunderstanding how the language feature works, since the odds are much higher that they misunderstood.

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.

In any case, given that I just ran into this issue in production code, and that it's something that seems to be frequently misunderstood, I thought that I'd bring it up as a reminder in the hopes that more people would understand the actual behavior and not make this mistake.

- Jonathan M Davis

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.

On Sunday, 17 November 2024 at 16:47:39 UTC, Nick Treleaven wrote:
> [...]
> 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.

Problematic is valid code like

   if (auto arr = make_me_an_array ()) {
      ...
   }

There is another interesting aspect as Steven pointed out in that
2015 discussion [1]:

   || The "truthiness" of an array says it's true ONLY if both the
   || pointer and length are 0.
   | Ugh, *false* only if they are both 0. If either are not zero,
   | then it's true.

And later he stated [2]

   | arr.ptr == null -> arr contains a null pointer (length could
   | technically be non-zero).

My question is: Is it possible that a valid D program gets into a
state where an array has ptr == null and length > 0? If so, how?

Such a "null array" can at least not be printed:

   import std.stdio;

   void main ()
   {
      int [] arr;

      struct V {
         size_t length;
         void *ptr;
      }
      auto q = cast (V *) &(arr);
      (*q).length = 2;

      writeln (arr); // segfault in formatValueImpl
   }


[1] Re: string <-> null/bool implicit conversion
    https://forum.dlang.org/post/mr54qg$15qj$1@digitalmars.com

[2] https://forum.dlang.org/post/mr72sf$2sc7$1@digitalmars.com

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