Forbid dynamic arrays in boolean evaluation contexts

Steven Schveighoffer schveiguy at yahoo.com
Wed Mar 27 09:35:21 PDT 2013


On Wed, 27 Mar 2013 08:18:34 -0400, Vladimir Panteleev  
<vladimir at thecybershadow.net> wrote:

> On Wednesday, 27 March 2013 at 03:03:13 UTC, Steven Schveighoffer wrote:
>> 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.

Well, somebody wrote the code that way.  Whether they considered possibly  
pointing at a non-null value or not, I don't know.  But I assume they  
picked null from convenience and from the fact that nulls are a perfectly  
valid spot to point at for an empty array.

To say it is a bug is incorrect -- the spec does not call for null or  
non-null, the design is perfectly valid given the constraints.

>> 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.

I can only go on what I see in the code.  It seems certain that whoever  
wrote it is deliberately returning null.  It's also REQUIRED by the spec  
for "" to return a pointer to a readable 0, so null is not possible.  I  
can only assume, with a very high degree of certainty, that if that  
requirement was gone, "" would also return null given the behavior of the  
array literal code, and the assumption the same developer wrote both.

I am not 100% certain, as I didn't write the code, I guess you caught me?   
It's more like 99% certain.  This of course is my opinion.

-Steve


More information about the Digitalmars-d mailing list