Table lookups - this is pretty definitive

[Dmitry Olshansky]

03-Apr-2014 05:05, Walter Bright пишет:
> On 4/2/2014 3:06 PM, bearophile wrote:
>> Walter Bright:
>>
>>> I don't see why not. Note that we couldn't do this for extern(C)
>>> functions, or
>>> variadics, or caller functions with parameters that need destruction, or
>>> parameters that may refer to any locals. That last constraint might be a
>>> doozy, however.
>>>
>>> Why not submit an enhancement request to bugzilla?
>>
>> So what does it happen if I (by mistake or by ignorance) try to use
>> this on a
>> function that doesn't satisfy one of those requirements?
>
> Then it won't tail call it.
>
>> D can't give an error in that case because it's a big breaking change.
>> So is D in that case just
>> silently not performing the tail call as the programmer meant?
>
> That's right.
>

 From this it seems to me that once again you've walled yourself out of 
this question and going to frame it as an optimization.

Tail-call has 2 sides to it:

a) An optimization for functions that return with a call expression. I'd 
leave this case an optimization because it also has an undesirable 
effect on call stack, hindering debugging.

b) An explicit instruction to switch execution to another function. This 
doesn't have any unexpected effects, and failing to make a tail-call 
will change the semantics of code. This is critical for certain kind of 
code, it simply doesn't work if tail-call is not a jump.

I agree that nothing prevents doing optimization of
return foo(args);
in case a) if optimization is enabled, and this is something GCC/LLVM 
already do.

But more importantly there should be an explicit tool for the case b), 
with syntax:
goto foo(args);
that will fail to compile if tail-call is not possible.

Because the alternative of double-checking on every compiler that 
"return foo(args)" in all the right places is optimized the right way is 
fragile, and would turn out to be an _ongoing_ waste of time.

-- 
Dmitry Olshansky