Andrei's Google Talk

[Steven Schveighoffer]

On Wed, 04 Aug 2010 10:15:29 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 08/04/2010 06:38 AM, Steven Schveighoffer wrote:
>> On Tue, 03 Aug 2010 17:56:44 -0400, Walter Bright
>> <newshound2 at digitalmars.com> wrote:
>>
>>> bearophile wrote:
>>>> 27.50, "transactional file copy": this example was script-like, and
>>>> as short
>>>> as possible to fit into one single slide, so in this case I think  
>>>> using
>>>> enforce() is OK. But in true programs I suggest all D programmers to  
>>>> use
>>>> DesignByContract with assert() more and to use enforce() less. Among
>>>> other
>>>> things enforce() kills inlining possibilities and inflates code. In
>>>> D.learn I
>>>> have seen people use enforce() in a situation where DbC is designed
>>>> for. I
>>>> think the D community needs to learn a bit more DbC, and in my
>>>> opinion to do
>>>> this the leaders have to lead the way.
>>>
>>> There's a misunderstanding here. Contract programming is for detecting
>>> program bugs. enforce() is for detecting and handling errors such as
>>> disk failures and bad user input.
>>>
>>> They are COMPLETELY DIFFERENT and must not be conflated.
>>
>> Yes, but as has been discussed and resolved on phobos mailing list,
>> usage errors should not be handled via uncaught exceptions. I think the
>> example is flawed in that regard. I wouldn't bring it up, but people who
>> haven't followed that discussion might get the wrong idea from this
>> example.
>
> Well I agree with the spirit but let me say this. If all I want is a  
> short script that does the right thing, I don't care whether failure  
> comes with a stack trace caboose. So I don't think the example is flawed  
> at all - it stands as a short correct script that does something useful.

Yes, the utility would be useful and would serve its purpose as a  
quick-and-dirty script.  I shouldn't have labeled it flawed :)

A more polished script would be less careless about usage messages, but  
would require more code.

-Steve