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
