DIP: Tail call optimization

[Dietrich Daroch via Digitalmars-d-announce]

On Monday, 11 July 2016 at 15:48:08 UTC, Ola Fosheim Grøstad 
wrote:
> On Monday, 11 July 2016 at 15:27:54 UTC, Dietrich Daroch wrote:
>> 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.
>
> Just keep in mind that a @tco constraint is much easier to 
> implement than @boundedStack. I don't do tail calls much, but I 
> think you have the right idea for a system level language: 
> specify the constraints you want to hold rather than explicitly 
> laying out everything manually. That's what I expect from a 
> modern system level language.
>
> I have previously argued in favour of something similar like 
> @boundedStack, but there is quite a bit of resistance against  
> (and lack of interest in) solid static analysis in the D 
> community.
>
> You probably will save yourself some trouble by reading one of 
> the numerous threads touching on stack handling in D. Here is 
> one:
>
> http://forum.dlang.org/post/logpgo$2k1d$1@digitalmars.com


Previous discussion seems to favour @unboundedStack as it can 
become a requirement to go beyond the stack-size-safe operations 
effectibly tracking where stack overflow may happen and encourage 
detailed review of those functions.

Walter's concern is that a great amount of the D runtime library 
would make this unpractical. Maybe another attribute to promise 
bounded stack without a proof might be required to make the idea 
viable.
I really think that this kinds of proofs are somewhat natural in 
D, as it follows ideas like contracts, and safe/trusted 
attributes.