See my prior comment: IMO it's the caller's issue that (guaranteed) TCE is needed. The callee should not have to do anything.

One of the things I forget to give thanks to the Rust designers for is the default of immutability. I remember my days in a Java environment where policy was "everything needs to be declared final" (so "final" got spattered all over the place) with zero nostalgia. Requiring TCE callees to explicitly represent themselves as TCE-friendly would be the same sort of abomination.

I feel like I’ve seen elsewhere that the argument there is that you often must have this optimisation working in algos that rely on it or you will get stack overflows. Having a keyword to force it then becomes a very useful thing, vs relying on hopes that future compiler versions and different arch targets will all discover the optimisation opportunity.

> Having a keyword to force it then becomes a very useful thing, vs relying on hopes that future compiler versions and different arch targets will all discover the optimisation opportunity.

Having a way to guarantee TCO/TCE is essential for some cases, yes. GP's question, though, was why a keyword specifically and not a hypothetical attribute that effectively does the same thing.

A keyword seems nicer to me. I think the only reason to use attributes is to avoid the work of adding actual new syntax, but seeing as they've already done that...