std.xml validity checking is absurd

[monarch_dodra]

On Thursday, 7 February 2013 at 22:36:53 UTC, Andrei Alexandrescu 
wrote:
> On 2/7/13 5:27 PM, Vladimir Panteleev wrote:
>> On Thursday, 7 February 2013 at 22:22:09 UTC, Stewart Gordon 
>> wrote:
>>> This is what I've found: Validity checking is done in an in 
>>> contract!
>>
>> I've ran into the same problem with std.base64. DbC doesn't 
>> seem to be a
>> generally well-understood concept.
>
> 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).
>
> Andrei

"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.

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.

He'll call my sqrt with negative numbers, and the in will never 
get called, and sqrt will crash horribly.

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

Please see also:
http://d.puremagic.com/issues/show_bug.cgi?id=4720
http://d.puremagic.com/issues/show_bug.cgi?id=6549

And finally, this old thread about the subject, which kind of 
fell into darkness:
http://forum.dlang.org/thread/jamrtmgozgtswdadeocg@forum.dlang.org