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.
