std.xml validity checking is absurd

[bearophile]

Andrei Alexandrescu:

> I don't think std.math.sqrt should validate its input using a 
> contract.

Why not? Returning a NaN is an option. But in a language that 
supports contracts, its precondition should only accept 
non-negative inputs.


> That druntime uses a contract to verify length in slice is an 
> antipattern.

Why?


> I don't think we should put contracts on the front burner.

Why? (And I don't agree).


>That's why TDPL dedicates a whole chapter to it (separate from 
>error
handling!). Apparently that didn't make a dent in the Universe 
:o).<

Instead of not putting contracts on the front burner, I suggest 
to think about the causes, find some of them, and then try to fix 
the causes.


> For whatever reason, people don't use contracts or they misuse 
> them. I have no idea why. The obvious argument is that people 
> would use contracts if this or that bug were fixed, but there's 
> past evidence suggesting the contrary.

I am using D contracts in my code. I think there are three or 
more reasons for people not using D contracts a lot:
- C/C++/Python/Java programmers don't know much about contract 
programming. They look like improved asserts, while they require 
a bit different mindset. Learning a different mindset requires 
time and work. This is an important point but I think this isn't 
the most important one.
- D contracts miss some important parts, the pre-state is one of 
them. Other problems are present (as they say "move in contract 
checking to the caller side").
- I think Phobos contracts get removed. This reduces their 
usefulness. If you have a feature X in your language and you 
aren't using it in your standard library, then a bit of redesign 
is needed.
- D is used a system language, where often programmers think of 
asserts as things present only in debug builds. But maybe 
contracts should have a different compiler switch to be stripped 
away (http://d.puremagic.com/issues/show_bug.cgi?id=9482 ).

I also think it's good to reduce the usage of enforce() in 
contracts, because I think it doesn't help the cause of D 
Contracts. I think well implemented Contracts don't need 
exceptions.

Bye,
bearophile