On Sunday, July 9, 2017 1:51:44 PM MDT kdevel via Digitalmars-d-learn wrote:
> > You also shouldn't rely on it returning null for a null input, even when it currently does that.
>
> I assumed that a non-null string is returned for a non-null input.

There are going to be functions that return null rather than an empty slice of the original array. You really can't rely on getting an empty array instead of a null one from a function unless the documentation tells you that. For most purposes, there is no practical difference between a null array and an empty array, so very little code is written which cares about the difference. The only place where I would expect a function in a library to distinguish is if its documentation says that it does (e.g. if returning null means something specific or if it specifically says that the result is a slice of the input).

In general, relying on whether a dynamic array is null or not outside of code that you control or functions that are explicit about what they so with null is risky business.

Sometimes, I wish that null were not treated as empty, and you were forced to allocate a new array or somesuch rather than having null arrays just work - then you could actually rely on stuff being null or not - but that would also result in a lot more segfaults when people screwed up. The status quo works surprisingly well overall. It just makes it dangerous to do much with distinguishing null arrays from empty ones.

- Jonathan M Davis