September 27, 2008 Re: Article on code features in C++ by Scott Meyers + sidebar on D implementation by Bartosz Milewski | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | "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. |
September 27, 2008 Re: Article on code features in C++ by Scott Meyers + sidebar on D implementation by Bartosz Milewski | ||||
---|---|---|---|---|
| ||||
Posted in reply to Lionello Lunesu | 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) { } } |
September 27, 2008 Re: Article on code features in C++ by Scott Meyers + sidebar on D implementation by Bartosz Milewski | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sergey Gromov | > 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.
|
Copyright © 1999-2021 by the D Language Foundation