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 repo](https://github.com/dlang/DIPs/pull/6)


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 people).

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 this.

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 languages. Probably recursion is more natural to them than manually unrolling to avoid a problem that did not existed in their previous language.

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 call stack.

Reply via email to