Walter:
>The reason that took so long was that few people were using DbC effectively,
>so it was a low priority. I originally had high hopes that DbC would produce
>dramatic improvements in code quality, but the real world results were
>disappointing.<
After many years and many failed hopes, I think there is no silver bullet in
programming, so maybe nothing is able to produce "dramatic improvements in code
quality".
But even if this is true, some things are able to improve coding a bit, like
unit testing, a well semantically defined language, syntax coloring, quick
compile-run cycles, OOP for certain kinds of programs, DbC, and so on. Each of
such things improve the situation only a little, but such improvements pile up
and most programmers when have tried them don't want to go back to miss those
things.
I have learnt to know and use DbC on D, and while it has not caused dramatic
improvements in my code, I like to use it now and then, it has found some of
the bugs in my code and more. I am appreciating D DbC enough that sometimes I
miss it when I write Python code, so sometimes when I write OOP Python code, I
add home-made class invariants and I call them manually from methods. In one
situation this has allowed me to finish some hairy Python code in a very tight
time schedule.
Regading D implementation of DbC I'd like:
- DMD to use a not-release build of Phobos when I compile my D code in
not-release build (or some similar solution). So Phobos will be free to use
asserts instead of enforce in many more situations (even if not in all
situations). This will allow more inlining, allow to use "nothrow" tags more
frequently, and avoid some performance problems currently present (confirmed by
timings and profiling) in Phobos caused by enforces;
- To see some acceptable solution for the "old" (pre-state) problem. On this
there are some ideas, but I don't think there is some accepted proposal yet.
This is not an indispensable feature of DbC, but it allows to increase its
power and applicability significantly enough (and designers of C#4 DbC has
found ways to solve this problem, so I presume there is some way to solve it in
D too);
- To see some Bugzilla DbC bugs removed. One or more of them is related to how
const/immutable badly interacts with the result return value used by
out(result){}.
Bye and thank you,
bearophile
