On 2/8/13 6:25 AM, monarch_dodra wrote:
"in" and "out" contracts themselves are flawed in D in any case, given they are part of the "called" code, as opposed to "caller" code.
What would be the right design and implementation?
This makes them absolutely no different than an assert. The problem is that an assert is "internal" validation, whereas an "in"/"out" is supposed to be a handshake between the caller/callee. If I write an "sqrt" function, and document it as "Please, only give me positive numbers", and then write a contract for it, and then compile my lib in release, the caller will have no way of "signing" my contract.
I don't think std.math.sqrt should validate its input using a contract.
He'll call my sqrt with negative numbers, and the in will never get called, and sqrt will crash horribly.
It'll return NaN.
A *BLATANT* example of this limitation is slice operations: They have an in contract stating that the slices need to be the same length. However, this contract will never ever get run, for anyone, because druntime is built and distributed in release. Long story short, even if I compile in debug, the code will silently run erroneously. http://d.puremagic.com/issues/show_bug.cgi?id=8650
That druntime uses a contract to verify length in slice is an antipattern. It should use a sheer test and throw.
Please see also: http://d.puremagic.com/issues/show_bug.cgi?id=4720
This is legit. We should have a way to separate contracts from body in the general case.
http://d.puremagic.com/issues/show_bug.cgi?id=6549
This, too, is legit.
And finally, this old thread about the subject, which kind of fell into darkness: http://forum.dlang.org/thread/jamrtmgozgtswdade...@forum.dlang.org
Yeah, makes sense. I don't think we should put contracts on the front burner. 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.
Andrei
