View mode: basic / threaded / horizontal-split · Log in · Help
June 27, 2005
Re: Empty String == Empty Array == Empty Static Array?
On Mon, 27 Jun 2005 23:37:46 +0200, Tom S  
<h3r3tic@remove.mat.uni.torun.pl> wrote:
>>> Thus if (arr) checking ptr makes little sense IMO, but for you it's  
>>> the  desired behaviour.
>>   "if (arr)" does not check the ptr, it checks the reference, comparing  
>> it  to null/0 just like it does for _every other type_ in D. It just  
>> happens  that for arrays a null reference cannot exist, instead you get  
>> a reference  to a struct with a null data pointer, thus the confusion.
>
> And it happens to make little sense in most cases.

The rule is simple "if (x)" compares x with null/0.

In the case of an array you're comparing the array *reference*, just like  
any other reference. You don't actually need to know any more than that.

Of course, arrays are not just references, they cannot be null, this fact  
is not important till you write "if (x.length == 0)" without checking for  
null, in which case bug avoided! :)

If you don't think "if (x)" is explicit enough, don't use it, use "if (x  
is null)" or "if (x !is null)" or "if (x.length == 0)". In fact, I'd  
recommend that if you're coding with more than just yourself.

> Simple operations should be simple. 99% of time I want to check if an  
> array is empty.

And it's simple "if (x.length == 0)". Arrays cannot be null so this is  
safe, simple, explicit, obvious, perfect (that last one might be an  
exageration)

> if (foo) then means 'does foo have valid data ? / does foo make any  
> sense ?'.

Nope, "is foo null or 0"

> if (obj)  <-- obj reference is not null ?

Yep, "is obj null or 0"

> if (arr)  <-- array is not empty ?

Nope, "is arr null or 0" (arr being like a reference here)

Notice the pattern?

In short "if (i)" == is 'i' null or 0
What type is 'i'? Who cares! it doesn't actually matter the same rule  
applies to all types (except a struct/union for which this is illegal)

> That's the test I mean by default. Instead by default I'm getting a  
> something that can only be a source of bugs :/

Anything you do not understand (not you specifically, people in general)  
will be a source of bugs.

> But it seems that I'm alone with my view on the subject, so I'll just  
> shut up and go play with my toys.

You might be alone, I doubt it tho, every crazy view has at least one  
other supporter ;) (joke!)

Argument is a good thing so long as both parties listen and attempt to  
understand the other point of view. If you're not doing that, you're not  
arguing, you're simply saying things at someone. (again, not you  
specifically, people in general)

>>> Thus I suggested disallowing implicit conversions from arrays to  
>>> bool's  in order to make sure the programmer specifies exactly he/she  
>>> wants.
>>   I dont think arrays have a stronger argument for this than any other  
>> type  in D.
>
> No ? Arrays are the only type in D that can be asked for their members  
> (ptr, length) when they are null

Sure.

> (when in your reasoning, the nullness of the ptr member means nullness  
> of the array reference).

Or rather is equivalent to. A null data ptr means the array reference  
would be null, only it cannot be.

> This doesn't happen to be true with classes nor structs /+ excluding  
> static members +/

Sure, so what? I mean yes, they're different, but why shouldn't you be  
able to say "if (arr)" and check the nullness of the reference. That's  
what it does, effectively, even if it actually uses the data ptr and the  
reference itself is not null.

>>> Some people will quickly grasp the difference between nullness and   
>>> emptiness of arrays. But others will find their code buggy due to the   
>>> implicit conversion.
>>   People simply need to learn that an array is not a reference, not a   
>> struct, but a unique type with properties of both. It's a reference to  
>> a  struct and cannot be null. I dont think the implicit conversion is  
>> the  cause of confusion, I think the nature of arrays is, once that is  
>> grasped  confusion vanishes.
>
> Confusion vanishes, bugs dont. Once one understands the nature of the  
> for loop, they won't write code like:
>
> for (....);
> {
> }
>
> or will they ?  /+ yes, I know that dmd reports an error here +/

Sure, there will always be human error, nothing you do can remove that  
(except to remove humans...). DMD tries to lessen it (as in the case shown  
above).

I dont think making if (x) will lessen human error, and it'll certainly  
make arrays inconsistent with all other types in D. Perhaps it's my C  
background but if (x) has always made sense to me.

Regan
June 27, 2005
Re: Empty String == Empty Array == Empty Static Array?
Regan Heath wrote:
> If you don't think "if (x)" is explicit enough, don't use it, use "if 
> (x  is null)" or "if (x !is null)" or "if (x.length == 0)". In fact, 
> I'd  recommend that if you're coding with more than just yourself.

I will. But that is just a convention. Just like doing 'if (const == 
var)' instead of 'if (var == const)' in C/C++. That doesn't prevent new 
coders that do not use this convention from committing the same error 
over and over.


> Nope, "is foo null or 0"
> 
>> if (obj)  <-- obj reference is not null ?
> 
> 
> Yep, "is obj null or 0"
> 
>> if (arr)  <-- array is not empty ?
> 
> 
> Nope, "is arr null or 0" (arr being like a reference here)

Yes ! Exactly. "is arr null" <=> "is arr.ptr null" ; "or 0" <=> "or 
arr.length == 0". I would really like 'if (arr)' to work that way.


> Notice the pattern?
> 
> In short "if (i)" == is 'i' null or 0
> What type is 'i'? Who cares! it doesn't actually matter the same rule  
> applies to all types (except a struct/union for which this is illegal)

Ok... but from what you're saying it's apparent to me that:
'if (arr)' should mean 'if (arr.ptr !is null && arr.length > 0)'. Then 
it would be consistent.


>> But it seems that I'm alone with my view on the subject, so I'll just  
>> shut up and go play with my toys.
> 
> 
> You might be alone, I doubt it tho, every crazy view has at least one  
> other supporter ;) (joke!)
> 
> Argument is a good thing so long as both parties listen and attempt to  
> understand the other point of view. If you're not doing that, you're 
> not  arguing, you're simply saying things at someone. (again, not you  
> specifically, people in general)

You're right, I'm just surprised that I don't hear any other opinions on 
this matter than yours (which I appreciate of course). Maybe everyone's 
too busy. Wait... I should be studying for my exams <lol>


> I dont think making if (x) will lessen human error, and it'll certainly  
> make arrays inconsistent with all other types in D. Perhaps it's my C  
> background but if (x) has always made sense to me.

Ok, what about the other apprach, 'if (x)' checking both the nullness 
and emptiness at once ?


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
June 28, 2005
Re: Empty String == Empty Array == Empty Static Array?
On Tue, 28 Jun 2005 01:32:05 +0200, Tom S  
<h3r3tic@remove.mat.uni.torun.pl> wrote:
> Regan Heath wrote:
>> If you don't think "if (x)" is explicit enough, don't use it, use "if  
>> (x  is null)" or "if (x !is null)" or "if (x.length == 0)". In fact,  
>> I'd  recommend that if you're coding with more than just yourself.
>
> I will. But that is just a convention. Just like doing 'if (const ==  
> var)' instead of 'if (var == const)' in C/C++.

Yep.

> That doesn't prevent new coders that do not use this convention from  
> committing the same error over and over.

You're right. It wasn't intended to help new coders write code, but rather  
help any coder reading another coders code. (that's a tongue twister!)

>> Nope, "is foo null or 0"
>>
>>> if (obj)  <-- obj reference is not null ?
>>   Yep, "is obj null or 0"
>>
>>> if (arr)  <-- array is not empty ?
>>   Nope, "is arr null or 0" (arr being like a reference here)
>
> Yes ! Exactly. "is arr null" <=> "is arr.ptr null" ; "or 0" <=> "or  
> arr.length == 0". I would really like 'if (arr)' to work that way.

In D as in C null *is* 0. C doesn't make a distinction. D is the same (to  
a more limited degree perhaps?).

When you compare any variable 'x' using 'if' i.e. "if (x)" you're saying  
is the variable 'x' null/0, you're not comparing any property or member of  
'x' with null/0. To do so would be a hidden implicit (it's not explicitly  
naming the member) and very unintuitive operation IMO.

Before you note that in the case of an array it's comparing the data ptr,  
I'll remind you that this occurs because in all cases where an array  
reference would be null/0, but cannot be, the data pointer *is* null/0.

Compare that to the length property which can be 0 when the reference  
would not be null/0. i.e.

char[] arr = "";

In other words the data pointer *is* the reference for purposes of  
detemining whether the reference is null/0.

>> Notice the pattern?
>>  In short "if (i)" == is 'i' null or 0
>> What type is 'i'? Who cares! it doesn't actually matter the same rule   
>> applies to all types (except a struct/union for which this is illegal)
>
> Ok... but from what you're saying it's apparent to me that:
> 'if (arr)' should mean 'if (arr.ptr !is null && arr.length > 0)'. Then  
> it would be consistent.

No, to be consistent "if (x)" must always compare the variable "x" with  
null/0 not implicitly compare one or more of it's members to null/0 or  
something else.

If we don't care about consistency then this change would mean that:
  char[] emp = "";
  char[] nul = null;

  if (emp) ; //false
  if (nul) ; //false

Meaning, basically, an array with no items is not ever 'true'. This might  
be nice as it's the most common case, but it's still inconsistent. I think  
I prefer consistency here.

>>> But it seems that I'm alone with my view on the subject, so I'll just   
>>> shut up and go play with my toys.
>>   You might be alone, I doubt it tho, every crazy view has at least  
>> one  other supporter ;) (joke!)
>>  Argument is a good thing so long as both parties listen and attempt  
>> to  understand the other point of view. If you're not doing that,  
>> you're not  arguing, you're simply saying things at someone. (again,  
>> not you  specifically, people in general)
>
> You're right, I'm just surprised that I don't hear any other opinions on  
> this matter than yours (which I appreciate of course). Maybe everyone's  
> too busy. Wait... I should be studying for my exams <lol>

It might be a timezone thing, I notice more posts here late night (for  
me). I've also noticed less posts over the last few months (exams maybe?).  
Worry not! I will always share my opinion ;)

>> I dont think making if (x) will lessen human error, and it'll  
>> certainly  make arrays inconsistent with all other types in D. Perhaps  
>> it's my C  background but if (x) has always made sense to me.
>
> Ok, what about the other apprach, 'if (x)' checking both the nullness  
> and emptiness at once ?

So, "if(x)" <==> "if(x.ptr==null && x.length==0)". That would work,  
because neither of these cases is possible:

A) x.ptr!=null && x.length==0
B) x.ptr==null && x.length!=0

but, if neither of those cases is possible then you can simply choose and  
check one or the other for null/0 as it currently does, checking ptr.

I think ptr is a better choice than length for reasons mentioned above.

Regan
June 28, 2005
Re: Empty String == Empty Array == Empty Static Array?
Regan Heath wrote:
> On Tue, 28 Jun 2005 01:32:05 +0200, Tom S  
> <h3r3tic@remove.mat.uni.torun.pl> wrote:
> If we don't care about consistency then this change would mean that:
>   char[] emp = "";
>   char[] nul = null;
> 
>   if (emp) ; //false
>   if (nul) ; //false
> 
> Meaning, basically, an array with no items is not ever 'true'. This 
> might  be nice as it's the most common case, but it's still 
> inconsistent. I think  I prefer consistency here.

Ok... but I still am stubborn and think both of these arrays are 'false' 
as they dont make much sense while printing :) But I agree on your point 
about consistency. I'll just have to set a trap in the 'if' expression 
code writing routine in my neural networks to signal me that I should be 
checking 'arr.length' instead of 'arr'. And I *hope* it will work.



> It might be a timezone thing, I notice more posts here late night (for  
> me). I've also noticed less posts over the last few months (exams 
> maybe?).  Worry not! I will always share my opinion ;)

Thanks. Get ready cuz I'll have more issues to discuss ;) /+ But 
probably after the tomorrow's exam +/


>> Ok, what about the other apprach, 'if (x)' checking both the nullness  
>> and emptiness at once ?
> 
> 
> So, "if(x)" <==> "if(x.ptr==null && x.length==0)". That would work,  
> because neither of these cases is possible:

// you probably meant "if (!x)"


> A) x.ptr!=null && x.length==0
> B) x.ptr==null && x.length!=0
> 
> but, if neither of those cases is possible then you can simply choose 
> and  check one or the other for null/0 as it currently does, checking ptr.

A) is possible.

char[] foo = ""

which means I have to check for foo.length instead of foo.ptr to see if 
it contains any useful data. In this case it contains an out-of-bounds '\0'.



-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
June 28, 2005
Re: Empty String == Empty Array == Empty Static Array?
On Tue, 28 Jun 2005 10:42:13 +0200, Tom S  
<h3r3tic@remove.mat.uni.torun.pl> wrote:
> Regan Heath wrote:
>> On Tue, 28 Jun 2005 01:32:05 +0200, Tom S   
>> <h3r3tic@remove.mat.uni.torun.pl> wrote:
>> If we don't care about consistency then this change would mean that:
>>   char[] emp = "";
>>   char[] nul = null;
>>    if (emp) ; //false
>>   if (nul) ; //false
>>  Meaning, basically, an array with no items is not ever 'true'. This  
>> might  be nice as it's the most common case, but it's still  
>> inconsistent. I think  I prefer consistency here.
>
> Ok... but I still am stubborn and think both of these arrays are 'false'  
> as they dont make much sense while printing :)

Yeah, or any other time you're only interested in the contents of the  
array and not whether it exists or not.

> But I agree on your point about consistency. I'll just have to set a  
> trap in the 'if' expression code writing routine in my neural networks  
> to signal me that I should be checking 'arr.length' instead of 'arr'.  
> And I *hope* it will work.

At least it won't ever segv :)

>> It might be a timezone thing, I notice more posts here late night (for   
>> me). I've also noticed less posts over the last few months (exams  
>> maybe?).  Worry not! I will always share my opinion ;)
>
> Thanks. Get ready cuz I'll have more issues to discuss ;) /+ But  
> probably after the tomorrow's exam +/

Good luck.

>>> Ok, what about the other apprach, 'if (x)' checking both the nullness   
>>> and emptiness at once ?
>>   So, "if(x)" <==> "if(x.ptr==null && x.length==0)". That would work,   
>> because neither of these cases is possible:
>
> // you probably meant "if (!x)"

Yeah, thanks.

>> A) x.ptr!=null && x.length==0
>> B) x.ptr==null && x.length!=0
>>  but, if neither of those cases is possible then you can simply choose  
>> and  check one or the other for null/0 as it currently does, checking  
>> ptr.
>
> A) is possible.
>
> char[] foo = ""

Doh! True.

> which means I have to check for foo.length instead of foo.ptr to see if  
> it contains any useful data. In this case it contains an out-of-bounds  
> '\0'.

Yeah, that's a whole other issue! (damn compatibility!)

Regan
June 28, 2005
Re: Empty String == Empty Array == Empty Static Array?
Regan Heath wrote:

>>> It might be a timezone thing, I notice more posts here late night 
>>> (for   me). I've also noticed less posts over the last few months 
>>> (exams  maybe?).  Worry not! I will always share my opinion ;)
>>
>>
>> Thanks. Get ready cuz I'll have more issues to discuss ;) /+ But  
>> probably after the tomorrow's exam +/
> 
> 
> Good luck.

Thanks :)



>>> A) x.ptr!=null && x.length==0
>>> B) x.ptr==null && x.length!=0
>>>  but, if neither of those cases is possible then you can simply 
>>> choose  and  check one or the other for null/0 as it currently does, 
>>> checking  ptr.
>>
>>
>> A) is possible.
>>
>> char[] foo = ""
> 
> 
> Doh! True.
> 
>> which means I have to check for foo.length instead of foo.ptr to see 
>> if  it contains any useful data. In this case it contains an 
>> out-of-bounds  '\0'.
> 
> 
> Yeah, that's a whole other issue! (damn compatibility!)

/+ I assume it was irony +/ In this case it *is* /damn/ compatibility 
cuz I have to check for 'if (str.length)'. Checking 'if (str)' works 
most of the time just like the former but then it fails on empty strings.


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
June 28, 2005
Re: Empty String == Empty Array == Empty Static Array?
On Tue, 28 Jun 2005 11:07:01 +0200, Tom S  
<h3r3tic@remove.mat.uni.torun.pl> wrote:
>>>> A) x.ptr!=null && x.length==0
>>>> B) x.ptr==null && x.length!=0
>>>>  but, if neither of those cases is possible then you can simply  
>>>> choose  and  check one or the other for null/0 as it currently does,  
>>>> checking  ptr.
>>>
>>>
>>> A) is possible.
>>>
>>> char[] foo = ""
>>   Doh! True.
>>
>>> which means I have to check for foo.length instead of foo.ptr to see  
>>> if  it contains any useful data. In this case it contains an  
>>> out-of-bounds  '\0'.
>>   Yeah, that's a whole other issue! (damn compatibility!)
>
> /+ I assume it was irony +/ In this case it *is* /damn/ compatibility  
> cuz I have to check for 'if (str.length)'. Checking 'if (str)' works  
> most of the time just like the former but then it fails on empty strings.

Actually I was talking about C compatibility this time.

IIRC hard coded/static strings have a \0 on the end to be compatible with  
C strings which must end in \0.
Regardless you can create an empty array in other ways too eg.

char[] tmp = "testing123";
char[] emp = tmp[0..0];

Regan
June 28, 2005
Re: Empty String == Empty Array == Empty Static Array?
Regan Heath wrote:
> Actually I was talking about C compatibility this time.
> 
> IIRC hard coded/static strings have a \0 on the end to be compatible 
> with  C strings which must end in \0.

Yup I know. It happens that I've also got a C/C++ background...



> Regardless you can create an empty array in other ways too eg.
> 
> char[] tmp = "testing123";
> char[] emp = tmp[0..0];

I see. Funnily, setting emp.length to 0 will null the pointer although 
length already is 0. A nice example of why you want it changed ;)



-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
June 28, 2005
Re: Empty String == Empty Array == Empty Static Array?
On Tue, 28 Jun 2005 14:12:33 +0200, Tom S  
<h3r3tic@remove.mat.uni.torun.pl> wrote:
> Regan Heath wrote:
>> Actually I was talking about C compatibility this time.
>>  IIRC hard coded/static strings have a \0 on the end to be compatible  
>> with  C strings which must end in \0.
>
> Yup I know. It happens that I've also got a C/C++ background...

:)

>> Regardless you can create an empty array in other ways too eg.
>>  char[] tmp = "testing123";
>> char[] emp = tmp[0..0];
>
> I see. Funnily, setting emp.length to 0 will null the pointer although  
> length already is 0. A nice example of why you want it changed ;)

Yep, that is exactly the problem I want fixed.

Regan
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home