I have counted about 200 usages of std.contracts.enforce() inside Phobos. Can you tell me what's the purpose of enforce() in a language that has built-in Contract Programming?

And what are the purposes of std.contracts.AssumeSorted()? Is it useful for something?

Bye,
bearophile
(I know this is not the digitalmars.D.learn newsgroup).

bearophile wrote:
> I have counted about 200 usages of std.contracts.enforce() inside
> Phobos. Can you tell me what's the purpose of enforce() in a language
> that has built-in Contract Programming?

You need to read TDPL for that :o).

> And what are the purposes of std.contracts.AssumeSorted()? Is it
> useful for something?

AssumeSorted was an experiment. I think it has drawbacks that I don't know how to address, so I'll retire it.


Andrei

bearophile wrote:

> I have counted about 200 usages of std.contracts.enforce() inside Phobos.
> Can you tell me what's the purpose of enforce() in a language that has
> built-in Contract Programming?

I'd think of it this way: enforce() is part of defensive programming, and contracts are related to software testing.

> And what are the purposes of std.contracts.AssumeSorted()? Is it useful
> for something?
> 
> Bye,
> bearophile
> (I know this is not the digitalmars.D.learn newsgroup).

bearophile wrote:
> I have counted about 200 usages of std.contracts.enforce() inside Phobos. Can you tell me what's the purpose of enforce() in a language that has built-in Contract Programming?

I can see two benefits:

1) enforce throws object.Exception, which is "the root of the exception hierarchy"; hence enforce errors can be caught with the same general catch(Exception) clause [*].

On the other hand, assert throws a type that is out of the Exception hierarchy: core.exception.AssertError

2) As a bonus, the word 'enforce' fits the purpose better than 'assert'

3) (the other 2 :p) The format of the message of the uncaught exceptions is a little better (e.g. no @ sign before the file name)

Ali

* Note: Actually, Throwable is at the top of the exception hierarchy, but I've heard before that the top exception class should be taken to be Exception; perhaps for user applications?

>You need to read TDPL for that :o).

Please don't start replying to queries in this fashion. Not everyone has the wherewithal to get a copy of a book such as TDPL. Especially seeing as you're the author, this kind of reply just looks like whoring for the book. I'm not saying that's what it is, just what it can look like.

I've got TDPL on the way from Amazon, by the way. I just don't want to see this reply, and wanted to express my distaste.

Bernard Helyer wrote:
>> You need to read TDPL for that :o).
> 
> Please don't start replying to queries in this fashion. Not everyone
> has the wherewithal to get a copy of a book such as TDPL. Especially
> seeing as you're the author, this kind of reply just looks like whoring
> for the book. I'm not saying that's what it is, just what it can look
> like.
> 
> I've got TDPL on the way from Amazon, by the way. I just don't want to
> see this reply, and wanted to express my distaste.

All right, all right.

Basically there's a marked difference between contract checking (which verifies the architectural integrity of a program) and error handling (which deals with errors that occur in correct programs). Contracts help with the former, enforce helps with the latter.

The differences are marked enough that TDPL dedicates a separate chapter to each.


Andrei

On Wed, 16 Jun 2010 00:18:03 -0700, Andrei Alexandrescu wrote:

> Bernard Helyer wrote:
>>> You need to read TDPL for that :o).
>> 
>> Please don't start replying to queries in this fashion. Not everyone has the wherewithal to get a copy of a book such as TDPL. Especially seeing as you're the author, this kind of reply just looks like whoring for the book. I'm not saying that's what it is, just what it can look like.
>> 
>> I've got TDPL on the way from Amazon, by the way. I just don't want to see this reply, and wanted to express my distaste.
> 
> All right, all right.
> 
> Basically there's a marked difference between contract checking (which verifies the architectural integrity of a program) and error handling (which deals with errors that occur in correct programs). Contracts help with the former, enforce helps with the latter.

I think any confusion regarding this may stem from the fact that enforce
() resides in std.contracts.

Personally, I think it's worth moving it to object.d, but maybe it's too late for that?  Anyway, I love enforce() -- it's become my standard error handling tool.

-Lars

Andrei Alexandrescu wrote:
> Basically there's a marked difference between contract checking (which verifies the architectural integrity of a program) and error handling (which deals with errors that occur in correct programs). Contracts help with the former, enforce helps with the latter.
> 
> The differences are marked enough that TDPL dedicates a separate chapter to each.

Yes, I agree it is extremely important to separate the concepts of contract checking from error handling.

Ali Çehreli wrote:
> bearophile wrote:
>> I have counted about 200 usages of std.contracts.enforce() inside Phobos. Can you tell me what's the purpose of enforce() in a language that has built-in Contract Programming?
> 
> I can see two benefits:

The difference is not based on those 3 points, but on what Andrei wrote here. Contracts and error checking are completely distinct activities and should not be conflated.

On 06/16/2010 04:15 PM, Walter Bright wrote:
> Ali Çehreli wrote:
>> bearophile wrote:
>>> I have counted about 200 usages of std.contracts.enforce() inside
>>> Phobos. Can you tell me what's the purpose of enforce() in a language
>>> that has built-in Contract Programming?
>>
>> I can see two benefits:
>
> The difference is not based on those 3 points, but on what Andrei wrote
> here. Contracts and error checking are completely distinct activities
> and should not be conflated.

Could you please explain them? There are many people here that don't understand the difference between these two concepts (including me). So maybe we are too dumb, maybe those concepts are not generally known or maybe the explanation is not very well clear in the documentation.