[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: block-scope finalization
- From: Patrick Donnelly <batrick@...>
- Date: Thu, 14 Jan 2016 12:42:50 -0500
On Thu, Jan 14, 2016 at 7:38 AM, Tom Sutcliffe <email@example.com> wrote:
> I'd add one suggestion however, which would be instead of "local <mark> name" there is a new one-word keyword to indicate this special meaning, perhaps "blocklocal name".
> Doing this would avoid the sorts of ambiguity/potential for mistakes that C constructs like "char* foo, bar" introduce when more than one variable is declared (written like that you might think that bar was a char* not just a char). Also I've just never liked multi-word types/modifiers like C's "unsigned int". I'd also point to Lua's use of "elseif" rather than "else if" as a previous example of where one token is preferred over two.
This will likely complicate assignment from functions that return
multiple values. Take io.open:
local <mark> f, err = io.open"foo"
I don't really want this to become the new way of doing things:
f, err = io.open "foo"
It would be better to annotate each name somehow when it is declared,
in my opinion.
> I'd suggest also that it might be simpler to not have the requirements that this only takes one variable which must be initialised - since presumably you must still be allowed to reassign to the variable (including assigning it nil) and thus there shouldn't be a requirement that the variable never changes its value during the block scope, it seems a bit confusing to require that it have a value at the start. I assume that only the value which the variable had at scope exit would be the thing that got __close()d? And having a single "blocklocal" keyword makes it clearer that the block-ness applies to every variable declared and avoids even having to document that "local foo, block bar" isn't valid.
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.
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.