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.