against enforce

[Steven Schveighoffer]

On Mon, 28 Mar 2011 10:28:04 -0400, Kagamin <spam at here.lot> wrote:

> Steven Schveighoffer Wrote:
>
>> This is really a question of optimization, not error catching.  If
>> something will always be the same, and it has already been tested, there
>> is no reason to test it again.
>
> Optimization is not a question of error catching, only if it's smart  
> enough to not interfere with error catching, but we have only blunt  
> method of -release switch. Thus optimization becomes question of error  
> catching.

Yes, the instrument is too blunt, which is why we are having this  
discussion ;)

But the question is still not *whether* to test for errors but *when*.   
The ideal is to avoid testing for them when they could not possibly occur  
(i.e. after testing during development proves there is no error).

The whole point of using assert and contracts only in development code is  
so you can instrument all your code with comprehensive, possibly slow  
performing, tests while testing, and take them all out for shipping.  But  
the mechanisms provided do not allow expression of when an error can occur  
(during testing or during production) *per call*, only per function.  We  
need it per call to be correct.

Made even more difficult is that we are discussing library functions,  
which can't possibly know whether to test the inputs they get unless the  
functions are private.  You can take the "better safe than fast" approach,  
but it leaves no room for performance upgrades (as shown by the poor  
performance of phobos in comparison tests by the likes of bearophile and  
others).  You can take the "not my problem" approach and leave it up to  
the caller to test inputs, but we don't provide an easy way for a user to  
test inputs in production code for when its needed at production time.

My opinion is that Phobos should opt for "not my problem" because 90% of  
the time, the input comes from deterministic sources that only need be  
tested during development.  All we need for that is a phobos compiled in  
non-release mode to test against.  It's always possible to add more tests  
*outside* the phobos call for when they are needed.  Then we should look  
into adding ways to have functions specify how to test their inputs during  
production in a DRY way.

But of course, this path makes code that uses Phobos more prone to  
errors.  It may be worth having all the enforce checks if we can do  
something like prevent all buffer overflow attacks.  I'm not sure of the  
right answer.

-Steve