On Monday, 11 July 2016 at 17:31:23 UTC, Dietrich Daroch wrote:
On Monday, 11 July 2016 at 16:27:38 UTC, Andrew Godfrey wrote:

* It must not be ignorable by the compiler.

* It must generate an error if that compiler would be unable to do the TCO. Otherwise, the compiler *may* (not "must") apply the TCO, unless compiled under (some optimization level, please specify), in which case it *must* apply TCO.

One difficulty with this is the words "that compiler". I.e. other compilers are free to be unable to make the TCO. This means that by using this feature, you have made your code non-portable.

I think that noticing problems while porting it it's better than having it crash unexpectedly as it would currently happen.

Sure, non-portability that causes a guaranteed compiler error, is better than other kinds of non-portability. But it's still non-portable. That is distasteful enough that you probably need to make a more compelling case; factorial is a "toy" function that's not enough - on its own - to justify adding a feature.

I personally feel like it is a neat idea, and it may enable some programming styles that I'm not familiar with so I can't say they definitively they have no value. The reason I'm not familiar with them could be that I've never had this feature in a language I've used a lot. So there could be something here, BUT I also think it would need to be a portable feature, which implies much more rigorous rules that all compilers would have to follow. (They could still do TCO for more complicated situations, but those wouldn't interact with this feature; to make use of this feature you'd have to conform to the more rigorous rules).

P.S. You have proposed annotating the function with @tco - it seems more like it's the call site that needs to be annotated.

I'm not sure about how to do annotations on the call site. Would a new keyword be required?

I don't know this. (E.g. Are attributes allowed at the beginning of a statement?)

Reply via email to