DIP: Tail call optimization

[Dietrich Daroch via Digitalmars-d-announce]

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