April 10 2014 Meeting Notes

[Brendan Eich]

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