I'd like to propose a change to Socket to optionally raise
ConnectionTimedOut and ConnectionClosed on certain read operations.

For example, consider SocketStream>>#nextLine. It returns an empty string
on timeout, which is ambiguous with receiving an empty line. (I have also
seen this call repeatedly return an empty string when the other end has
closed the connection but the socket state doesnt yet reflect this).

It could be implemented with one of the following:

1) change #receiveDataTimeout:into:startingAt: to call #waitForDataFor:
which signals the exceptions, instead of
#waitForDataFor:ifClosed:ifTimedout.

2) create new methods eg #receiveDataSignalTimeout:.... and update
appropriate sender(s) eg SocketStream>>#upToAll:

3) add an instance variable (eg signal or shouldSignal boolean) to a)
SocketSteam or b) Socket, and condition
#receiveDataTimeout:into:startingAt: to call either #waitForDataFor: or
#waitForDataFor:ifClosed:ifTimedout.

--

1) simplest but raises compatibility issues. Returning quietly even with
 timeout specified, appears to be by design so this would be a design
change.

2) increases Socket bloat, and still requires changes in possibly multiple
callers in eg, SocketStream. Compatibility issues again.

3) If shouldSignal was a variable, Socket wouldn't need so many method
signatures (ditto timeout for that matter).

3a) more consistent with timeout var, but like timeout would require new
method signatures to pass this state on the stack to Socket.

3b) can switch the behavior of clients to exception-raising without
requiring any new method signatures like in 2), or impacting existing
clients (ie, if var not set, works as currently).

Arguably the variable belongs to Socket; it controls Socket behavior
(again, ditto timeout); then it wouldn't have to be passed on the stack.
Is changing Socket shape problematic?