Re: f.close() vs f:close()

[Peter Aronoff <telemachus@...>]

Viacheslav Usov <via.usov@gmail.com> wrote:
> I do not want to. I am saying that it is easy to mistype f.close() for
> f:close(), and then the result is... strange.
> 
> Given that closing stdout seems to have been impossible since at least
> 5.2, I would say io.close() should simply be made invalid and documented
> as such, making f.close() also a straight-forward error.

Ok, I see now. I would say that we are already (almost) where you want.

1. f.close() is a straight-foward error *if* the current default file is
   stdout. As someone else pointed out, in that case f.close() returns nil
   and an error message under Lua 5.3.4.
2. The reference manual specifies that f.close() “Without a file, closes
   the default output file”. The default output file is stdout unless the
   user says otherwise.
3. The reference manual also states “The table io also provides three
   predefined file handles with their usual meanings from C: io.stdin,
   io.stdout, and io.stderr. The I/O library never closes these files.”
4. Finally, the manual says “Unless otherwise stated, all I/O functions
   return nil on failure (plus an error message as a second result and
   a system-dependent error code as a third result) and some value
   different from nil on success.”

If you put all this together, I think it’s pretty much what you want,
except maybe for two things.

1. io.close() is allowed because it closes “the default output file”, but
   of course, the default won’t always be stdout. For that reason alone, it
   wouldn’t make sense to simply remove io.close.
2. The manual may be more brief than you’d like. You have to put things
   together to figure out all the repercussions of the various parts. But,
   to be honest, the manual is like that all the time.

P

-- 
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System