DIP33: A standard exception hierarchy

[H. S. Teoh]

On Wed, Apr 03, 2013 at 09:19:24AM -0700, Ali Çehreli wrote:
> On 04/02/2013 08:16 PM, Jesse Phillips wrote:> On Tuesday, 2 April
[...]
> > However D does allow nothrow functions to throw Errors. I wouldn't
> > say this would cause the program enter into an invalid state (memory
> > corruption) but it would be a bad state (contract violations).
> 
> There are some issues with contract programming in D. For example,
> some people think that whether the pre-conditions of a module to be
> compiled should be determined by the user of that module, not the
> library (e.g. Phobos).
> 
> Because the above is not the case today, if I write a function, I
> cannot put the function pre-conditions in 'in' blocks because I don't
> know whether my function is being called as an implementation of my
> module or as an API function. The API function foo() may also be used
> as part of the implementation of the same module. (Maybe the same
> pre-condition checks should be repeated in the 'in' block and in the
> body; as asserts and corresponding enforces.)

This is very bad. It makes greatly diminishes the value of DbC in D.
What are the obstacles preventing us from fixing DMD so that contracts
are compiled with user code instead of library code?


> For that reason, in general, I think that pre-conditions should by
> default be implemented as enforce() calls in the function body, not
> assert() calls in the 'in' blocks.
[...]

Yes, this is the result of the wrong implementation of putting contracts
in the called function rather than the caller. It makes 'in' blocks
useless when you don't have ready access to library source code.


T

-- 
Computers shouldn't beep through the keyhole.