Kevin Smith wrote:


    In this case we have try-finally statements as an existing
    feature.  The semantics of this feature is a bounded execution
    scope with a cleanup action on completion. This feature is widely
    used and has always been internally consistent and reliable,
    expect for catastrophic external failure or intervention (ie,
    externally imposed process termination, power failure, etc).
     People use it for all sorts of things, including bounded resource
    management.


Zeroing in on "cleanup action on completion": don't co-routines by nature prohibit us from reasoning in this way about completion? It seems to me that this shift is broader than just `try/finally`, although I agree that `try/finally` shows some particularly acute symptoms.

And I also agree that we should not provide gratuitous footguns. Unfortunately, though, I'm having a hard time forming an opinion on how disallowing `try/yield/finally` would balance out.

We're at risk of going around the design wheel again.

Python started by banning yield in try: and then added it, with GeneratorExit as a magic exception thrown from Python's implicitly-called generator.close method at a yield-in-try that would run the finally clauses.

When Igor Bukanov and I were working on ES4 and prototyping it in SpiderMonkey, Igor urged forcing a return instead of throwing a magic exception. He even persuaded Philip J. Eby on python-dev that forcing return was better, possibly even for Python (which IIRC then went in the direction of reifying control effects as exceptions).

Instead of kicking the can and dragging this out yet again, I'm ok with return automation as proposed. Yeah, we're doing a common-ish use-case affordance. No, it isn't the last case where scoped resource release will come up. But yes, it has precedent in other languages and it's useful.

BTW Dave Herman persuaded me we don't need to use a symbol for the name; 'return' is ok if 'next' is. The iteration protocol hooks via @@iterator, which returns an instance of something coded new implementations, so implementors can avoid using 'return' for a different purpose without conflict. IOW, one symbol-name is enough!

/be

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to