"Walter Bright" <newshound1@digitalmars.com> wrote in message news:gbjqan$2lh0$1@digitalmars.com...
> Lionello Lunesu wrote:
>> Very cool, and very useful.. I really wish D would support 'features' natively. nothrow, pure, they all share the same behaviour: nothrow function can only call other functions with nothrow; pure function can only call functions with pure.. etc... Can't this be generalized?
>
> Both pure and nothrow are deeply embedded into the semantic analysis. I don't see any way to generalize it. For example,
>
>  void foo() nothrow
>  {
>     try
>     {
>           throw new Bar;
>     }
>     catch (Object o)
>     {
>     }
>  }
>
> is valid code, while:
>
>
>  void foo() nothrow
>  {
>     throw new Bar;
>  }
>
> should issue a compile time error.

Is see your point.

Isn't that similar, though, to the functionality of "Relaxing feature constraints" from Scott Meyer's paper? The try-catch-scope can be considered "nothrow" because it can be called from other nothrow code. But inside the try-catch scope the constraint is relaxed and not-nothrow code (code that can throw) is accepted. I know next to nothing about compilers' inner workings, but it sounds like a small rule could be attached to try scopes.

L. 

In article <gbk27p$14n$1@digitalmars.com>, lionello@lunesu.remove.com says...
> 
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:gbjqan$2lh0$1@digitalmars.com...
> > Lionello Lunesu wrote:
> >> Very cool, and very useful.. I really wish D would support 'features' natively. nothrow, pure, they all share the same behaviour: nothrow function can only call other functions with nothrow; pure function can only call functions with pure.. etc... Can't this be generalized?
> >
> > Both pure and nothrow are deeply embedded into the semantic analysis. I don't see any way to generalize it. For example,
> >
> >  void foo() nothrow
> >  {
> >     try
> >     {
> >           throw new Bar;
> >     }
> >     catch (Object o)
> >     {
> >     }
> >  }
> >
> > is valid code, while:
> >
> >
> >  void foo() nothrow
> >  {
> >     throw new Bar;
> >  }
> >
> > should issue a compile time error.
> 
> Is see your point.
> 
> Isn't that similar, though, to the functionality of "Relaxing feature constraints" from Scott Meyer's paper? The try-catch-scope can be considered "nothrow" because it can be called from other nothrow code. But inside the try-catch scope the constraint is relaxed and not-nothrow code (code that can throw) is accepted. I know next to nothing about compilers' inner workings, but it sounds like a small rule could be attached to try scopes.

Try-catch is not an ultimate protection.  The nothrow requirement is relaxed only for a class of exceptions it catches.  The following code violates the nothrow contract:

 class Bar {}
 void foo() nothrow
 {
    try
    {
          throw new Bar;
    }
    catch (Exception e)
    {
    }
 }

> Try-catch is not an ultimate protection.  The nothrow requirement is relaxed only for a class of exceptions it catches.  

You're right.. Good point.

L.