search

tc39 / proposal-ptc-syntax

Discussion and specification for an explicit syntactic opt-in for Tail Calls.
http://tc39.github.io/proposal-ptc-syntax/
168 stars 8 forks source link

Allowing "non-eligible" tail calls #24

Open thysultan opened 5 years ago

thysultan commented 5 years ago

Not throwing in non-tail call eligible tail calls surfaces an opportunity to support the collapsing of stack traces.

This is related to:

Another potential benefit of STC is that we know what the developer is intending and can give warnings or errors for, for example, claiming they're about to do a tail call and not putting the call in tail position.

Instead of throwing/warning. There's often a use case for library authors to attempt to remove as much as possible of library specific "call-traces" from the stack trace, especially in production. For example Firefox has pursed something akin to this in their dev-tools experience.

This may be a problem for developers who use this information to debug their programs

This may also be an opportunity to provide framework and library authors the ability to explicitly opt-into or opt-out of displaying library specific stack traces that often plagues consoles in both Node.js and the Browser.

ljharb commented 5 years ago

That’d need to be an entirely separate proposal, and since stacks aren’t in the language yet pending https://github.com/tc39/proposal-error-stacks, it might be a bit too soon for it.

thysultan commented 5 years ago

It is however predicated on "ptc syntax" at least considering this in its design if we are to avoid yet another syntax grammar provisioned for the stack traces case; assuming that is a desirable goal to begin with.

ljharb commented 5 years ago

I don’t see how; the use case for opting out of stack frames applies to all functions, with or without tail call usage.