Lua 5.4 alpha: (yet more) toclose feedback

[Matthew Wild <mwild1@...>]

I have two issues with the current "toclose" implementation.

Firstly, it had initially passed me by that <toclose> is only valid in
single-variable local declarations. I'm curious what the rationale for
this is, given the widespread use of multiple-return functions,
including within 'toclose's primary usage example, io.open().

The 'val, err' return pattern is everywhere, including Lua's own
standard library. What is it envisioned that idiomatic file-opening
code would look like?

```
local _f, err = io.open("file.txt")
local <toclose> f = _f
```

?

Secondly, I'm going to bring up the can of worms that is... naming. I
personally don't care too much what it is called, but I feel that in
some cases naming in things like programming languages can be
important to help people grasp concepts and semantics.

Here is the list of names I've seen proposed so far on this list:

<toclose>
<autoclose>
<scoped>
<cleanup>
<onexit>
<finalize>
<resource>
<unwind>
<bind> (or <bound>)

Of this list I strongly prefer the last.

Here are some reasons against toclose:

  1) 'toclose' borrows a name from open/close, which is common
file/network oriented terminology, but it isn't always going to be
about opening/closing things (using the functionality for locking has
come up multiple times, for example).

  2) It is strange to "close" something twice, but this is the
behaviour if the same value is assigned to multiple locals using this
feature (I believe that behaviour is absolutely correct, but not
intuitive based on the naming).

  3) It feels like multiple words were used ("to close") just because
it was hard to find an accurate single word that explains what the
feature does succinctly. It also requires the manual getting even more
awkward than the syntax, growing it to the phrase "to-be-closed" in
most places.

Now some arguments in favour of 'bind':

  1) unlike "toclose", it also implies "const" - the word "bind" means
to semi-permanently join two things together (in this case the
variable and the value, or the resource represented by that value)

  2) while "open" and "closed" is a state of an object/resource and
generally it doesn't make sense to "close" something twice, there is
no reason a value cannot be bound to multiple variables, and therefore
no reason an __unbind metamethod couldn't be sensibly called twice

  3) it feels very natural (to a native English speaker at least) to
discuss 'bound variables', far more than the awkward hyphenated phrase
"to-be-closed" all the time.

  4) "bind" is 4 characters vs. 7 characters in "toclose" (so less
typing, less visual noise when reading code, less reason for people to
dislike the angle brackets)

These are the only two things that I feel are problematic with the
current implementation. The syntax discussions are interesting, but
most proposals have their drawbacks (I'm also not saying the current
syntax is perfect, but it does the job).

Regards,
Matthew