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
