Tail-call optimization in C is relatively recent

pprakashqwerty about 4 hours ago 34 commentsRead Article on lwn.net

FR version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

80% Positive

Analyzed from 852 words in the discussion.

Discussion (34 Comments)Read Original on HackerNews

drdexebtjl•25 minutes ago

Unless the language can guarantee TCO, I don’t feel comfortable writing tail recursive code and being at the compiler’s/interpreter’s mercy.

I think the framing of TCO as an optimization has been very unfortunate.

LukeShu•9 minutes ago

GCC has `[[gnu::musttail]] return`.

But yes, framing TCO as an optimization is unfortunate.

kenjin4096•about 3 hours ago

I think Anton is replying to me in that LWN article IIRC. I personally didn't know C only had tail calls that late and learnt something new there!

On the other hand, I am pretty new to the compiler space myself, and I count early 2000s as a pretty long time ago, though again it is not that far back considering how long other language implementations had tail calls like in ML or variants since 1980-90s.

pjmlp•about 2 hours ago

It still doesn't, this is a compiler specific language extension.

You won't find anything on ISO/IEC 9899:2024 about tail calls, like it happens on Scheme.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf

Section 3.5 of R7RS.

https://standards.scheme.org/official/r7rs.pdf

wahern•about 2 hours ago

A formal technical specification (TS) extension is already being drafted: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3582.pdf That's a step up from the usual proposals. I'm not sure what criteria is used to decide whether to first create a TS vs just incorporating a change into the working draft of the next standard.[1] _Defer also seems to be taking the TS route.[2]

1. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3886.pdf

2. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3928.pdf

leoc•about 1 hour ago

There's some discussion of how C29 defer ended up in a TS at https://thephd.dev/c2y-the-defer-technical-specification-its... .

pjmlp•about 1 hour ago

Well, even if that lands on the official standard, that means C29 as probable release year for C2y, plus adoption of the exact form across compilers to be able to rely on it being available.

mmsc•about 3 hours ago

and TCO was added then removed from js! https://stackoverflow.com/a/54721813

This leads to fun stack-overflow bugs too in a lot of js code (one solution is to flatten: https://joshua.hu/javascript-infinite-tail-call-recursion-st...)

groundzeros2015•about 2 hours ago

Js really should have it. I think the shift in style from functional and manual prototype chains to Java classes is quite disappointing.

pfdietz•about 3 hours ago

Lack of TCO is also a common footgun for Scheme programmers using Common Lisp.

tialaramex•about 3 hours ago

This footgun is the reason I'm so enthusiastic about the Rust `become` keyword.

This proposal would give Rust a specific keyword which says that you intend TCO and so two things happen: 1. The compiler goes to more length to deliver TCO even where it wouldn't "just work" and 2. If it cannot deliver TCO your code doesn't compile, because you asked for TCO.

chriswarbo•about 2 hours ago

Sounds similar to @tailrec in Scala

I personally use the phrase "tail call elimination" when it's a requirement that can be relied on; and "tail call optimisation" when it might be implementation-dependent, context-dependent, limited (e.g. to immediate self-calls), etc.

StilesCrisis•about 3 hours ago

Sounds like clang::must_tail?

guenthert•about 3 hours ago

Only if they are using an insufficiently smart compiler. SBCL handles TCO just fine, as do a number of other implementations, see : https://0branch.com/notes/tco-cl.html

pfdietz•about 2 hours ago

Even SBCL doesn't do TCO at all times. Compiling at (debug 3) means no TCO.

Another related footgun is deep recursion of other kinds, for example when recursively traversing down lists. For long lists it's easy to exceed the stack size limit. The common idiom is to recur on list elements, but iterate or map to go along a list.

pjmlp•about 2 hours ago

Mostly because they forget Scheme is one of the few languages where TCO is part of the language standard, making it a required feature for any compliant implementation.

This has always been an issue regarding TCO support across programming languages.

pfdietz•about 2 hours ago

Well, and also because of the "I've been told in Scheme you should do it this way, so by gum I'm going to do it this way!"

swiftcoder•about 2 hours ago

> In 2001 Mark Probst implemented tail-call optimization in GCC

MSVC didn't add tail-call optimisation until sometime in the 2010s, IIRC.

I distinctly remember sending a tail-recursive C++ program to someone who developed on Windows, and it crashing, in the late mid-to-late 2000s.

throw-qqqqq•about 1 hour ago

MSVC stands for MicroSoft Visual C++ compiler AFAIK.

It famously doesn’t support a few features of C99.

They don’t really seem to care much about regular C support (non-C++).

pjmlp•about 1 hour ago

They officially saw no need for C support going forward.

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

Note,

"If you really need either of the following.....then we recommend that you consider using a different compiler such as Intel or gcc (short-term) and/or pressure your standards committee representatives to have ISO C++ include more of the C standard (longer-term)."

Which is kind of why nowadays clang is part of Visual Studio as well.

However, after Satya got into the whole Microsoft <3 FOSS, this changed a bit,

https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...

There are a few blogs after that, so at least up to C17 minus the optional parts from C11, the support is there.

It remains to be seen if anything C23 or later will ever come into MSVC, and then again, clang is part of VS installer.

nyeah•about 3 hours ago

>That quote is the article, and it's a little surprising that it's buried so far into the content

Is it really surprising in 2026? Today's online writing style is not primarily designed to communicate. It's designed to keep the reader 'engaged' for as long as possible. The reader's time is a resource to be extracted.

I'm absolutely not poking this author individually. It's the writing style of the net.

derdi•about 1 hour ago

I was wondering what this was in reference to; it's not in reference to TFA here. It's a quote from https://bytecode.news/posts/2026/08/because-it-s-not-fun-eno..., so presumably you meant to post this over at https://news.ycombinator.com/item?id=49242245.

nyeah•about 1 hour ago

Oh, good point, thanks.

hnfvovpje4•about 1 hour ago

Clear, useful, done

messe•about 3 hours ago

> In 2001 Mark Probst implemented tail-call optimization in GCC with a separate calling convention; he lists the limitations of the then-existing tail-call optimization in GCC in section 6.4, among them: "It cannot handle indirect calls" (which would have been used in tail calls for interpreter dispatch).

Relatively recent being a quarter of century? Or at least a fifth of a century for indirect calls[1] (GCC 3.4.6 is the earliest I see on Compiler Explorer, released March 2006).

[1]: https://godbolt.org/z/vvcnn54oM

coliveira•about 1 hour ago

For people who passed their 30s, everything that happened after their 20th birthday is recent. For me, September 11 is recent memory, as well as the 2008 great recession.

derdi•about 1 hour ago

Given that GCC was first released in 1987, that would mean that tail call optimization, including of indirect calls, has been around for more than half of GCC's lifetime. So it's indeed fair for the parent article to say that "[GCC has] had tail-call optimizations for most of [its] existence".