std.xml validity checking is absurd

[Andrei Alexandrescu]

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/jamrtmgozgtswdadeocg@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