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.

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

> 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.