On 14 May 2012 23:54, Timon Gehr <timon.g...@gmx.ch> wrote: > On 05/15/2012 12:14 AM, Alex Rønne Petersen wrote: >> >> On 14-05-2012 23:59, Timon Gehr wrote: >>> >>> On 05/13/2012 06:13 PM, Alex Rønne Petersen wrote: >>>> >>>> Hi, >>>> >>>> If memory serves me right, there were some proposals in the past to add >>>> a @noreturn attribute to the language. Where did this go? >>>> >>>> In writing unwinding mechanisms for my VM, I find myself actually >>>> needing some sort of @noreturn function attribute that would tell the >>>> compiler that the function does not return, rather than having to insert >>>> an assert(false); statement. >>>> >>> >>> What about making the compiler detect this pattern instead of adding an >>> attribute? I think it expresses exactly what you want to express, and it >>> does not require additional syntax. >>> >>> void foo()out{ assert(false); }body{ ... } >> >> >> While that might be an easier way to do it, I'm not sure if that would >> have unintended side-effects (admittedly, I can't think of any upfront). >> > > Side effects: > > - You wouldn't have to add the (completely redundant) assert(false) to the > call site anymore. > > - Ideally, the compiler will then optimize the code based on the pattern, > namely, assertions that are unchecked in release mode. That may or may not > be desirable. > => Fix: Add 'hlt' to end of each method that has assert(false) out in > release mode, and ban return statements from its body. > > I think it could go either way, but having both @noreturn and out{ > assert(false); } seems somewhat redundant to me.
1) hlt is horribly x86. :~) I would simply let the function "drop off" the end without cleanup, regardless of stack state. 2) The point of @noreturn is that the function should not be able to return conventionally, ie: may still return to the caller by throwing an exception that is caught. 3) It should be an error if the function is non-void. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';