On 4/2/2014 12:03 PM, Dmitry Olshansky wrote:
SwitchCallStatment:
     goto CallExpression;

Semantics:
Same as that of a function call expression except:
a) Can Switch-Call only to a function with the same return type.
b) Anything below this statement is unreachable, i.e. treat it as return.
c) Stack frame of the current function is overwritten with that of switched-to
function. In other words after a switch-call stack looks as if the switched-to
function was called instead in the first place.

The last point is what modern tail-call optimizations do when one has 2
functions that tail-recurse to each other. They overwrite stackframes on such
tail calls.

How is this different from simply recognizing "return foo(arg);" as being a 
goto?


However this only happens with certain optimization switch which IMO makes the
thing totally unreliable. In fact I even observed that I could implement
threaded-code interpreter by relying on tail-call optimization with LDC, but
only when compiling with all optimizations enabled. Unoptimized builds simply
blowup stack. This "semantics are tied to optimization" is a situation that I
hate about C/C++ and would hope to address in D.

Doesn't seem terribly different than the "force inline" feature discussion.

Reply via email to