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.

Reply via email to