Revisit choice for channel senders to use Result

[aturon]

The fact that senders use Result has always struck me as a bit odd, and with the introduction of Sink, makes channels somewhat finicky to compose. I'd like to revisit whether this is the right choice to bake in by default, vs requiring a "flattening" transformation in the cases where you do want to use Result.

(Another, more minor strike against this choice is the inconsistency with oneshot, which is on its way to being more of a channel-like abstraction.)

[alexcrichton]

Yeah I'd kinda prefer to not send results as well, but do we have another error type for the channel? Oneshots have a concrete error type of "disconnected", but for streams that's done through ending the stream.

Of course it's possible that we could say that the error type is just never generated... (e.g. it's just a generic w/ a phantomdata)

[aturon]

Right, or (), or ! once that's stable.

[alexcrichton]

I'd feel kinda bad going to () specifically because it's never actually produced, and ! I'd be hesitant for as it's just not stable yet and will take awhile to propagate...

In the meantime I feel like it's better to make use of the error type and send results than to hardwire it to a generic or (), though

[aturon]

In the meantime I feel like it's better to make use of the error type and send results than to hardwire it to a generic or (), though

That doesn't really make sense to me. Just because the error type is there doesn't mean we have to use it, and the Result situation makes channel usage more complicated for clients that don't need it (which I suspect is the common case).

Note that we have plenty of examples of unused errors: consider Read/Write on any in-memory data structure.

I do agree that making it generic over the error is going to be a pain, but we can provide a ChannelError newtype which wraps () for now, and will wrap ! later on.

[carllerche]

This probably relates to #206

[aturon]

Another related issue: the choice of stream::iter to require Result.

[carllerche]

IMO, the error type of the stream should be used to indicate a scenario where the stream was terminated abruptly due to an error condition.

In some cases, it may be that it is impossible for a stream to terminate abruptly, in which case ! would be appropriate.

[alexcrichton]

Ok well I saw at least one location where we may want enum Void in the Sink PR, so we could perhaps just reuse that here for the error type (I'd prefer something uninhabited to ())

[alexcrichton]

And yes this is related to #206 and yes stream::iter would likely change as well...

[alexcrichton]

SPSC is removed, MPSC includes this change, and the old channels are deprecated, so closing.