DIP: Tail call optimization

[Dietrich Daroch via Digitalmars-d-announce]

On Monday, 11 July 2016 at 14:36:22 UTC, Andrew Godfrey wrote:
> On Monday, 11 July 2016 at 10:25:36 UTC, Tofu Ninja wrote:
>> On Sunday, 10 July 2016 at 13:15:38 UTC, Andrew Godfrey wrote:
>>> Btw here's a thread from 2014 that touches on the idea of a 
>>> "tailrec" annotation. At the time, Walter viewed the 
>>> optimization as the compiler's business and not something 
>>> he'd elevate to a language feature:
>>>
>>>
>>> http://forum.dlang.org/post/lqp6pu$1kkv$1@digitalmars.com
>>
>> I find it odd that something like tail recursions that 
>> actually makes certain things possible that wouldn't be 
>> otherwise is seen as only an optimization, when things like 
>> inlining which really is only an optimization is seen as 
>> important enough to have a pragma.
>
> I agree. Maybe Walter has reconsidered since then. He did also 
> say, though, that he thinks D supports enough different 
> programming styles already.
>
> Would you be satisfied with a pragma? I'd intuited (but could 
> be wrong) that the focus of your proposal was to get a compiler 
> error if someone makes a change to a recursive function, that 
> causes the compiler to be unable to apply the TCO optimization. 
> If that is your focus, it has heavy implications and the 
> feature can't just be a pragma.

Pragma does not seem enough, at least current pragmas can be 
ignored by the compilers 
(http://dlang.org/spec/pragma.html#predefined-pragmas), but if 
it's required for tco it can make it.


I've been thinking about changing @tco for @boundedStack, as 
it'll really reflect guarantees on functions while implicitly 
asking for TCO on functions that require it. But the fact that 
most functions should be marked as @boundedStack is something 
that bothers me.
The complement, @unboundedStack, might be better, as it would 
explicitly mark the functions that might cause stack overflows so 
they drag required attention and would also force the compiler to 
do TCO where required.
Focusing on  stack size, rather than directly on TCO might even 
allow to guarantee that many D programs do not crash due to a 
stack overflow, which is a nice guarantee that not many 
languages, allow to express.
I'd like thoughts on this change of perspective.


BTW, I'm glad that discussion has arised, as it can only make the 
propossal better.