std.xml validity checking is absurd

[monarch_dodra]

On Friday, 8 February 2013 at 17:16:25 UTC, Ali Çehreli wrote:
> On 02/08/2013 08:18 AM, Dicebot wrote:
> > On Friday, 8 February 2013 at 16:11:14 UTC, Ali Çehreli wrote:
> >> As the module writer, I don't know whether my function is
> going to be
> >> used as an "API function" or as an "internal function" in
> somebody
> >> else's module.
> >
> > Then it is an API function, as far as I understand DbC, and
> should never
> > rely on contract to validate input.
>
> It is an internal function if I use it so:
>
> import std.math;
> import std.exception;
>
> void foo(double a, double b)
> {
>     enforce(a > b, "a must be greater than b");
>     sqrt(a - b);
> }
>
> void main()
> {}
>
> See how sqrt() is *not* on my module's API? I have already 
> enforced that my API function foo() is called correctly. My 
> call to sqrt() is an internal call of my module. Therefore the 
> checks inside sqrt() should not be repeated beyond my testing 
> stage.
>
> Ali

What is the point of an "in" contract, if not to check that the 
*caller* code is correct? Still assuming "sqrt" can't handle 
negatives, why bother with an "in", when you could just as well 
assert?

Heck, at this point, how is an "in" any different than a 
"version(assert) {...}", and an "out" an "version(assert) 
scope(exit) { ... }" ?

compile this program in debug:
//----
void main()
{
   auto a = [1, 2, 3];
   auto b = [1, 2];
   a[] += b[];
}
//----
Well herp dee derp! Look at it silently running and failing! The 
idea behind a debug build is that I should get an error for this 
kind of crap. But I don't. That's bad.

No end-user should be using a non-release version of druntime: 
That has  already been validated. On the other hand, once 
compiled in release, all the checks that *should* be executed 
when the caller is trying to validate his code *aren't* run.

Regardless of "where" the contract is compiled in (implementation 
detail), its inclusion (or lack thereof) should be at the 
callers' discretion.