Tail recursion?

Topics: C# Language Design
May 15, 2014 at 4:40 PM
Does Roslyn support tail recursion for C#? If not, are there plans to support it?
Developer
May 19, 2014 at 6:17 PM
ryantrem wrote:
Does Roslyn support tail recursion for C#? If not, are there plans to support it?
Roslyn doesn't do anything special for tail recursion at this time. There have been discussions in the past of what we might do to help, but there are no concrete plans.
May 19, 2014 at 7:29 PM
nmgafter wrote:
ryantrem wrote:
Does Roslyn support tail recursion for C#? If not, are there plans to support it?
Roslyn doesn't do anything special for tail recursion at this time. There have been discussions in the past of what we might do to help, but there are no concrete plans.
Does CIL have tail-recursion support? If so, I would think a tail return method(params); syntax--even if it doesn't make it until the next rev--should make it easy for code to use tail returns when appropriate, without the semantic difficulties that might arise if tail recursion were something the compiler simply inferred.
May 19, 2014 at 8:21 PM
supercat wrote:
nmgafter wrote:
ryantrem wrote:
Does Roslyn support tail recursion for C#? If not, are there plans to support it?
Roslyn doesn't do anything special for tail recursion at this time. There have been discussions in the past of what we might do to help, but there are no concrete plans.
Does CIL have tail-recursion support? If so, I would think a tail return method(params); syntax--even if it doesn't make it until the next rev--should make it easy for code to use tail returns when appropriate, without the semantic difficulties that might arise if tail recursion were something the compiler simply inferred.
MSIL/CIL has had a tail opcode since 1.0 and some languages like F# use it, but C# never has.

The current JIT engine does apply some tail recursion optimization if it identifies looping recursion in specific circumstances if the assembly is AnyCPU and the process is running in 64-bit. The RyuJIT sounds like it will enable this optimization in more situations. Having the compiler explicitly emit the tail opcode would probably be more efficient. I'd think that the compiler would be smart enough to do this implicitly, just like F# does.
May 19, 2014 at 8:42 PM
Halo_Four wrote:
The current JIT engine does apply some tail recursion optimization if it identifies looping recursion in specific circumstances if the assembly is AnyCPU and the process is running in 64-bit. The RyuJIT sounds like it will enable this optimization in more situations. Having the compiler explicitly emit the tail opcode would probably be more efficient. I'd think that the compiler would be smart enough to do this implicitly, just like F# does.
An advantage of a tail return instruction versus implicit tail recursion is it will ensure that any changes which would preclude the use of tail conversion will cause compile-time rather than run-time failures. If code merely uses implicit tail recursion, a subtle change to a method might cause its stack requirement to jump from 500 bytes to 500,000. Such a change might not cause any immediate observable change in behavior, and might not be detected in testing, but could easily cause seemingly-random program failures at some later point down the line.