Re: TIP 301 obsolescence (Was: TIPs I'd like to see done)

>...>      [close -r|-w $ch]
>...>      [close $ch ?read|write?]
>...>      [close $ch ?r|w?] (by symmetry with [open])

I prefer the first, because adding options to close is like
leaving the door open for future changes, (like accepting more
than one channel to close).  Optional extra arguments used
as boolean flags are an anti-pattern, imho.
(just like "puts foo nonewline") 

> >  ... closing something that isn't open is an error currently.
> >  I think it should remain so for half-closes of non-open halves.
Shouldn't that fall into the general "do nothing gracefully"-corner?

>>>   - Does a half-close of (the proper side of) a mono-directional
>>> channel just close, or raise an error ?
> I propose to still raise an error because a half-close on a
> monodirectional channel indicates a false assumption on the channel's
> nature.

As far as I've gathered, there are only a limited number of
bidirectional channels, anyway:
  sockets, which principially only allow closing the 
       write-side separately.
  [open "|cmd" r+]-channels, which are two fd's in one channel
       and which can principially be closed individually, with
       no practical usecase yet for closing only the read side.
  (possibly "special") files (when opened for read-write), 
       which cannot be halfway-closed at all.