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.
