proposed @noreturn attribute

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Sat Jul 8 13:20:03 PDT 2017


On Sat, Jul 08, 2017 at 01:09:35PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/8/2017 5:17 AM, Andrei Alexandrescu wrote:
> > None ThisFunctionExits();
> > 
> > The compiler detects (without having anything hardwired about the
> > particular type "None") that the type None is impossible to create
> > and copy/move from a function, and therefore decrees the function
> > will never return.
> 
> That is a scathingly brilliant idea. It has another nice effect - the
> compiler doesn't have to diagnose:
> 
>    @noreturn int foo();
> 
> as an error!
[...]

Hmmm. Just to clarify, what exactly does @noreturn include? If I have a
function that calls exit(), that's @noreturn? What about a function that
always throws? Or a function that calls exec()? A function that always
ends in assert(0)? A function that context-switches to a different
thread / fibre and terminates this one?

Personally, I'm for this. It is useful for functions that constructs
then throws an exception, for example. It would be nice to be able to
call such a function from another function that returns non-void without
having to insert assert(0) into the latter to avoid the compiler
complaining that you failed to return a value.

As for Andrei's idea, it's pretty clever but we would need to
standardize the None type, otherwise we risk hard-to-read code when
everyone rolls their own None type with different names. An attribute
has the advantage that it will be universally understood.


T

-- 
It only takes one twig to burn down a forest.


More information about the Digitalmars-d mailing list