enforce()?

Michel Fortin michel.fortin at michelf.com
Mon Jun 28 05:16:07 PDT 2010


On 2010-06-28 07:17:53 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> On 06/28/2010 03:15 AM, Norbert Nemec wrote:
>> On 19/06/10 22:46, Andrei Alexandrescu wrote:
>>> On 06/19/2010 03:55 PM, bearophile wrote:
>>>> Inside Phobos2 I have counted about 160 usages of the "body" keyword.
>>>> I think contract programming can be used more often inside Phobos2
>>>> (and maybe some usages of enforce() can be turned into contract
>>>> programming because they are more similar to program sanity checks).
>>> 
>>> Walter and I discussed this and concluded that Phobos should handle its
>>> parameters as user input. Therefore they need to be scrubbed with hard
>>> tests, not contracts.
>> 
>> IMHO, this is plain wrong!
>> 
>> By this kind of decision, you are putting the library user under
>> tutelage. The D language is explicitly designed to allow the user to
>> take off the safety belt, but to do so at their own responsibility.
> 
> C APIs also check their arguments.

With C you don't have the option to turn the checks on or off. It's 
generally better to have them when you don't need them than not have 
them when you need them. With D, you can turn them on or off on a whim.

If the 'in' contract was enforced at the call site instead of inside 
the function, it'd be up to the one using a function to decide whether 
to check contracts or not. That's not an option in C, but it could work 
like that in D...

I agree though that with the way contracts are currently implemented 
this doesn't work very well. You have to recompile the library with 
contracts on, which in turn forces all the internal contracts inside 
the library to be evaluated. All this because you're trying to validate 
inputs you give to that library? Doesn't make sense. In that context I 
agree that checking explicitly at the library boundaries might be a 
more viable option (like in C).

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d mailing list