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?)
