DMD 1.027 and 2.011 releases

[eao197]

On Wed, 27 Feb 2008 10:42:07 +0300, Robert Fraser  
<fraserofthenight at gmail.com> wrote:

> eao197 wrote:
>> On Mon, 25 Feb 2008 12:44:15 +0300, Walter Bright  
>> <newshound1 at digitalmars.com> wrote:
>>
>>> Ary Borenszweig wrote:
>>>> Does this mean this will not compile:
>>>>  int foo(int[] someArray, int someIndex) nothrow {
>>>>     return someArray[someIndex];
>>>> }
>>>>  but this will:
>>>>  int foo(int[] someArray, int someIndex) nothrow {
>>>>     if (someIndex < someArray.length) {
>>>>         return someArray[someIndex];
>>>>     } else {
>>>>         return -1;
>>>>     }
>>>> }
>>>
>>> I don't know yet. But the idea is to do static checking of what can  
>>> throw.
>>  Just my $0.02 about nothrow and DesignByContract: I think that nothrow  
>> are incompatible with DbC. A function/method could have contracts or  
>> nothrow but not both of them. It is especially actual for virtual  
>> (non-final) methods. Suppose that some class has:
>>  class A {
>>   public void cleanup() nothrow { ... };
>> }
>>  so it could be safely used in 'finally' statement:
>>  A someResource = acquireResource();
>> try { ... /* some processing */ ... }
>> finally {
>>   someResource.cleanup; /* looks like exception-safe action */
>> }
>>  But if there is a derived class B, which overrides cleanup() with  
>> postcondition:
>>  class B : A {
>>   public void cleanup() nothrow
>>     out { ... some checking ... }
>>     body { ... some actions ... }
>> }
>>  and acquireResource() would return B instead of A, then the code above  
>> won't be exception-safe. Moreover the behaviour of  
>> 'someResource.cleanup' would depend on compiler switches.
>>
>
> So the code generated depends on compiler switches... Isn't this always  
> true? The "nothrow" spec could only actually be used when building  
> release mode, and in non-release mode code, exception handling frames  
> are always set up. This means that nothrow functions can still use  
> assert() and array indexing without worries, since these only throw  
> exceptions in non-release-mode code.
>
> Of course, then problems occur when mixing code compiled with different  
> switches...

I'm affraid that you misunderstand my point. When you use a[i] or new in  
nothrow function you always known what could happen. But if you call  
virtual method from any object you can't predict its behaviour. Because  
the method implementation in some derived class could define contract for  
that method. And you may don't known about it.

And becouse of this I think that 'nothrow' is a kind of function contract.  
And if a function defines such contract then it can't redefine it in  
derived classes.

-- 
Regards,
Yauheni Akhotnikau