View mode: basic / threaded / horizontal-split · Log in · Help
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
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
> 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.
Top | Discussion index | About this forum | D home