Article on code features in C++ by Scott Meyers + sidebar on D implementation by Bartosz Milewski

[Sergey Gromov]

In article <gbk27p$14n$1 at digitalmars.com>, lionello at lunesu.remove.com 
says...
> 
> "Walter Bright" <newshound1 at digitalmars.com> wrote in message 
> news:gbjqan$2lh0$1 at 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)
    {
    }
 }