Forbid dynamic arrays in boolean evaluation contexts

[Vladimir Panteleev]

On Wednesday, 27 March 2013 at 03:03:13 UTC, Steven Schveighoffer 
wrote:
> The design is that the pointer of a 0-length array when 
> allocating one is inconsequential.  Rather than allocate space 
> on the heap or designate space on the data segment, null is 
> available and free, and it happens to be the default you get 
> when you declare an array.

Allocating space on the heap?? You don't need to "designate" 
space anywhere - on the heap, stack, or data segment, because an 
empty array takes NO space. As I said before, ANY value for .ptr 
other than null would be good, even if it's cast(T*)1. What .ptr 
is pointing at is irrelevant, since the slice has 0 length, and 
indexing it with any index would be an out-of-bounds array access.

> The code is specifically designed

No. The code is specifically WRITTEN. For the third time: You 
don't know if this was a conscious design decision made with the 
distinction between null and empty arrays in mind, so please stop 
wording things like it was.

> I was not around when this decision was made, but it seems

> I wasn't there, I didn't make the decision, but it's implied in

This is what I wanted to clear up. Your previous posts were 
worded in such a way that you seemed absolutely certain of the 
reasonings for why the code ended up like that.

Many arguments in either direction could be presented by either 
side, but it doesn't change the fact that we don't know whether 
the current state of things was a result of careful planning or 
not. I could also present lengthy arguments in favor of why 
making [] have a non-null .ptr would have made more sense, and 
why I think that code's author disregarded the distinctions of 
non-null empty arrays, but as I said in my previous post, even if 
we knew the answers, they wouldn't change anything, as we can't 
change []'s behavior now.