Thread overview | |||||
---|---|---|---|---|---|
|
January 11, 2013 Adding noreturn and hidefromvtls attributes | ||||
---|---|---|---|---|
| ||||
Hello, Is there any change would could be seeing a noreturn attribute or way to hide a variable from the -vtls option in D in the near future? Sometimes it's desirable to indirectly throw an exception, especially if there's some work that needs to be done specifically relating to the exception about to be thrown, but you don't want to have to clutter your code with assert(false) every time you do. For example: void throwEintr (string funcName) pure noreturn { throw new Exception (funcName ~ "() was interrupted by the OS"); } void exacerbate (T) (const(T) exc, string msg) pure noreturn { throw new T (msg ~ ": " ~ exc.msg); } There are of course, a multitide of other potential uses for it On hiding from -vtls. Say you want to be alerted to any accidental thread-local variable declarations, but don't want the compiler yelling at you for ones you know you want. Such as: extern(C) __thread __hidefromvtls int errno; A working implementation of both is here: https://github.com/Chaiomanot/dmd Appolgies if this isn't the right place to post this, I couldn't find a suggestions forum. |
January 11, 2013 Re: Adding noreturn and hidefromvtls attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chaiomanot | Chaiomanot: > Sometimes it's desirable to indirectly throw an exception, > especially if there's some work that needs to be done > specifically relating to the exception about to be thrown, but > you don't want to have to clutter your code with assert(false) > every time you do. For example: > > void throwEintr (string funcName) pure noreturn > { > throw new Exception (funcName ~ "() was interrupted by the OS"); > } > void exacerbate (T) (const(T) exc, string msg) pure noreturn > { > throw new T (msg ~ ": " ~ exc.msg); > } If your patch enforcing that a function tagged with noreturn does not return (so core.stdc.stdlib.exit must be tagged with noreturn)? This feature was discussed recently, I think for LDC2. I think calling it @noreturn is a little better (despite it looks worse), because it isn't a very often used feature/need. > There are of course, a multitide of other potential uses for it If you want a chance to see that feature added to D, then you probably have to list all the different usages you can think of. A more general comment: in few years I have seen lot of wasted work done on D/DMD. So I suggest first to discuss a feature, to find some kind of (partial) consensus that it's an acceptable idea, and only then, try to implement it. Otherwise I think time is better spent fixing bugs, implementing popular (well voted) enhancement requests of Bugzilla, or even better helping the review of already written patches and applying them: at the moment creating more pull requests is not the top priority because currently there are about 115 open pull requests for DMD. Bye, bearophile |
January 11, 2013 Re: Adding noreturn and hidefromvtls attributes | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | > If your patch enforcing that a function tagged with noreturn does not return (so core.stdc.stdlib.exit must be tagged with noreturn)? It isn't currently compulsory. Any noreturn function will still compile without the attribute. If adopted, it would of course be prudent to make stdlib.exit noreturn (though I haven't bothered with it, as I haven't used stdlib.exit yet) > A more general comment: in few years I have seen lot of wasted work done on D/DMD. So I suggest first to discuss a feature, to find some kind of (partial) consensus that it's an acceptable idea, and only then, try to implement it. Otherwise I think time is better spent fixing bugs, implementing popular (well voted) enhancement requests of Bugzilla, or even better helping the review of already written patches and applying them: at the moment creating more pull requests is not the top priority because currently there are about 115 open pull requests for DMD. That's understandable, however I didn't add these because I wanted to improve D. I made them because my project called for them, and modifying the compiler felt cleaner than hacking the project. |
Copyright © 1999-2021 by the D Language Foundation