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
