DMD 0.148 release

Ivan Senji ivan.senji_REMOVE_ at _THIS__gmail.com
Tue Feb 28 02:52:07 PST 2006


Oskar Linde wrote:
> Kyle Furlong skrev:
> 
>> Oskar Linde wrote:
>>
>>>
>>> if (a !is null || b !is null)
>>>
>>> instead of:
>>>
>>> if (a || b)
>>>
>>
>> I would say that the second construct is much less reliable, 
>> maintainable, and safe than the first. Therefore, the type system 
>> should disallow the second with a pure boolean type.
> 
> 
> I have seen bugs introduced by changing
> 
> if(!a || !b)
> 
> into
> 
> if(a !is null || b !is null)

I would argue that the bug in the first place is coding something like 
!a || ! b.


> 
> And the double negation nature of !is null makes this quite hard to spot 
> (for both me and the one introducing the bug). This contradicts your 
> saying that it makes the code "much more reliable, maintainable and 
> safe". Consider the sentences:
> 

Ok lets add some values to a sentence... (let's say a and b are pointers)

> "If a or b"

if 0x01233d3f or 0x533123ff

What does that mean in any human language? Exactly nothing!

> 
> compared to:
> 
> "If a is not nothing or b is not nothing"

if 0x01233d3f isn't 0x00000000 or 0x533123ff isn't 0x00000000

> 
> Which one is easier to grasp and get right?

The second one, obviously. The first one has no meaning, second one has 
obvious and clear meaning, so there is no realy question here...

> 
> (!is also takes an extra step when it is parsed by the reader as "not 
> is" and then (in most western languages at least) has to be transformed 
> into "is not")

I don't see that as souch a big problem.
And if you think it is the same problem in if(!a || !b).
I read it like if not a or not b, and I have to ask myself what not a?
a not an elephant? not an apple? not an integer? not null? not not null?

> 
> What do you base your statements on? Do you have examples of where 
> (a||b) is less reliable or less safe? Why would it be less maintainable? 

(a||b) is an example of that :)

> It is clearer (less complex) an has a well defined semantic meaning.

It is more complex an doesn't have a well defined semantic meaning.
I mean Walter says it does, but the argument 1 is true in C, isn't 
really an argument. Why then do we have GC, delegates, templates,
why then do we have type safety after all? Why out/inout when everything 
can be done with pointers...

It is that way in C shouldn't be an exceptable argument for otherwise 
superb language like D. (IMHO)



More information about the Digitalmars-d-announce mailing list