Consider the 0.6 code:
pin = Base.Pipe()
...
Base.close_pipe_sync(pin.out)
This does not work in 0.7: one must pass in pin.out.handle, appropriately converted to either WindowsRawSocket or RawFD. The dependence on the OS thus spreads from stream.jl to user code.
Is this something that is this way for a reason, or is that a bug?
You are talking about “user code” that calls an internal undocumented Base function. What is wrong with close(pin)?
What if you don’t want to close both in and out?
The best you can do right now is e.g. close(Base.pipe_writer(pin)), I think. Base.pipe_reader and Base.pipe_writer are still undocumented internal functions at the moment, but at least they are higher-level functions that don’t expose pipe internals.
That sounds like a great suggestion. Thanks!
If you know you have a Pipe() object precisely, .in and .out are shorter to type. In an unusual variation, the pipe_writer / pipe_reader functions currently expose the internal implementation detail of AbstractPipe, and thus may actually be a bit less high-level than the using the field names themselves directly.