AP: Make :close behaviour the default in IO::Handle and Its Subclasses

[jnthn]

My feeling is something like:

• If you explicitly wrote a call to open or .open in your code, then you should be expected to write a matching call to .close. In the future, we should provide something akin to C#'s using, Python's with, and so forth in order to save the LEAVE .close boilerplate.
• If the file was opened for you to get an iterator of, say, words, lines, etc. then it should be closed for you at the end of the iteration, with the caveat that if you don't reach the end then you'll leak it. That is only really solvable through documentation - though arguably we could implement DESTROY in file handles and make it warn if you leaked the file handle without closing it, so people at least have a chance to spot the problem (this is what we do with unhandled Failures). The proposed limit parameter will handle the "I want the first N lines".

So, I guess that means that I think:

• IO::Handle methods should never auto-close by default
• IO::Path methods, where you don't write the open explicitly and so never obtain the handle, should do the close for you

This implies that a :close parameter defaulting to False on IO::Handle methods probably is the right thing already.

[jnthn]

And, to be clear, when IO::Path delegates to IO::Handle methods after opening, it would always pass :close. Alternatively, we could have a wrapping iterator that just calls .close when it sees IterationEnd, and then get rid of the :close parameters altogether. That might be even better.