Re: block-scope finalization

[Tom Sutcliffe <tomsci@...>]

> On 14 Jan 2016, at 5:42 pm, Patrick Donnelly <batrick@batbytes.com> wrote:
> 
> This will likely complicate assignment from functions that return
> multiple values. Take io.open:
> 
> local <mark> f, err = io.open"foo"

I don't think there's any obvious problem with 'err' getting the <magic> treatment as well? It (generally) won't be a table with a __close so the extra attribute won't have any effect? I occasionally find myself writing things like

local err
f, err = func(...)

because I want err to be local (if there is an error) but f should go straight into _ENV, but I don't think this will make that construct any more common than it is already.

> I think what Roberto was trying to say is you shouldn't assign a value
> that is not ready to be closed. For example, don't assign an unlocked
> mutex as an error may happen before you try to lock it. This would
> cause Lua to try to unlock (__close) it possibly causing an error.

I was assuming that if one is going to implement a __close metamethod, you have to go to effort of making sure it behaves itself, ie that it can be safely called multiple times, has no effect if the object in question isn't actually open (for whatever 'open' means in this situation) etc. That's established good practice in pretty much all "close" APIs I think. For Lua file objects for example, __gc already does this anyway, so no additional work would be necessary other than to make f.__close = f.__gc.

> Roberto didn't say this either but I suspect it was implied: if the
> value is not a function and has no __close metamethod (e.g. nil), then
> nothing happens when the "local <mark>" scope ends. This is consistent
> with the __gc metamethod. And actually, Lua doesn't even check the
> __gc metamethod for some types. Probably it wouldn't check __close for
> the same types.

Agreed, that's what I assumed.

Cheers,

Tom