On Sunday, 10 July 2016 at 12:01:54 UTC, Andrew Godfrey wrote:
On Sunday, 10 July 2016 at 05:03:46 UTC, Dietrich Daroch wrote:
Hi everyone (=
I've just added a new proposal to add a new attribute to
ensure TCO is applied.
The proposal is really simple, but I'm clueless on how to
implement it and also interested on getting feedback on it.
The proposal it's ready for merge on the new [DIPs
I'll chime in to give a counterpoint to the ... I'll say
"immature" discussion this generated.
Just my opinion:
Yes, an attribute to express something you expect the compiler
to do, has value. (Clearly some people on here don't have
experience with a codebase that is maintained by thousands of
Even if compilers aren't required to implement TCO, it could
work (compilers which didn't, would always give an error if you
used the attribute). But it would then feel weird to me to use
this attribute, knowing that some compilers would pass it and
some would fail it.
And compilers which always fail it, would feel pressure to do
better. Whether this is good depends on your outlook. D does
think of itself as "multi-paradigm", so maybe it should push on
Personally I could see myself making use of this, but not being
very sad if it didn't happen.
I do prefer your more verbose proposals over "@tco" - a short
abbreviation doesn't feel appropriate.
If you look at it as trying to make the build fail, then it's
definitely weird, but I think the point is to be able to state
your expectations and get feedback from the compiler on those,
the same as we already do with static typing.
I feel the same about the multi-paradigm thing, D supports
functional programming, so it definitely needs to ensure
executions are efficient for people coming from functional
Probably recursion is more natural to them than manually
unrolling to avoid a problem that did not existed in their
I personally prefeer longer names, but I felt that @tco followed
@nogc. We should consider what other languages have this kind of
annotation to get a reasonable name for newcomers.
Scala has @tailrec and it seeks the same goal as this DIP,
finding wrong assumptions and seeking to ensure having a bounded