close is underdocumented, and inconsistently implemented

[jakobnissen]

It's not clear how a closed IO object behaves. Will reading/writing from it error? Or will it simply return no bytes / write no bytes?
Will it change isreadable and iswritable?

Currently, this is all over the place for different IOs:

• For IOStream, closing the stream does not change iswritable or isreadable. Closed streams can be read, but return zero bytes. They can be written to, but write zero bytes.
• For IOBuffer, closing the stream unsets isreadable and iswritable. Trying to write to or read from it will cause an error.
• DevNull does not change is readable or writable state. A closed devnull can be read, returning zero bytes, but you can still write to it and if you do, it behaves like an open devnull.
• For stdin (the default REPL TTY one), closing it changes isreadable, but reading from it returns zero bytes

I propose we make it work consistently. I don't really care which one we end up with. I can pitch a PR changing them all to behave like IOStream and documenting the expected behaviour, if there is interest.

See also: #38703

[nhz2]

For reference in TranscodingStreams.jl, a closed IO returns false for isreadable and iswritable

Also, calling read, write, eof, bytesavailable, and so on error if the stream is closed.

The idea is to clearly distinguish a closed stream from an empty stream. Ref: JuliaIO/TranscodingStreams.jl#230

In InputBuffers.jl close is a noop for performance reasons. Ref: JuliaIO/InputBuffers.jl#3
I imagine the same argument holds for DevNull.

I think the underlying problem in #38703 is that closing a TranscodingStream closes the underlying IO object by default. This is not great since a close function doesn't make sense for many IO types, but they now need to implement this function to be compatible with TranscodingStream. In ZipArchives.jl I have my own IO wrapper types creating a sandwich around all third-party IO types to make sure they can never directly interact with each other to avoid this and other compatibility issues.

[vtjnash]

I think you should view close as a call to destroy the underlying object(s). The state afterwards is undefined (though not permitted to be UB)