Checking if a string is null

[Bruno Medeiros]

Manfred Nowak wrote:
> *** superseeding previous post ***
> 
> Bruno Medeiros wrote
> 
>> But first, explain me this, what do you mean the
>> "identityExpression is restricted to arrays containing at least
>> one element."? That doesn't seem to make sense.
> 
> In at least most definitions for relations on arrays in D the phrase 
> "all elements" is used.
> 
> Besides the fact that this phrase is informal its meaning seems to be 
> different from "rfo all x in the set S: P(x)". This latter phrase 
> clearly binds the predicate P to elements in existence.
> 

Erm, "all elements" is not in any different than "for all x in ...".

> Such existence quantor seems not to be included in the phrase "all 
> the elements are equal". This impressions is supported by this code 
> fragment:
>    writefln( "" is ""); // prints "false"
> 
> The definition for the relationalExpression supports the restriction 
> I phrased most prominently:
> 
> | For static and dynamic arrays, the result of the relational op is
> | the result of the operator applied to the first non-equal element
> | of the array.
> 
> I.e.: if there is no element, then there is no first element, then 
> the result of the relationalExpression is not defined. According to 
> the definition it is a bug that this code fragment is compilable:
>   writefln( "" < ""); // prints "false"
>  
> 

Ok, the relationalExpression, according to that spec quote, does seem to 
be restricted to arrays with one or more elements. But that's just the 
relationalExpression so far, it's not the case for the 
identityExpression or the equalityExpression.

>> That property "if `a is b' then `a == b'" holds for arrays with
>> zero elements as well.
> 
> Maybe that the implementation is holding this property. But the 
> specifications does not mention it. Therefore this property might not 
> be intended and the implementation is waiting for a case where this 
> property does not hold.
> 
> -manfred 
>       

True, the spec does not mention it. But you have to know that the spec 
has a certain relative lack of rigor (which is hoped will eventually be 
improved), and as such many times one needs to fill in the blanks with 
what is common and expected in these programming languages. That's the 
case with opEquals, the spec does not mention, but one expects it to 
have the same properties that a proper opEquals should (such as these: 
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#equals(java.lang.Object) 
).

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D