SharedChan should not exist, it should be Chan + clone()

[alexcrichton]

I've come to not like having SharedChan. The best justification for me is that if you write an api which takes a channel as an argument, you must make a choice of which one to take (SharedChan vs Chan). Having made a decision one way or the other, you will always be wrong at least some of the time.

There's some trickiness with this:

• Multiple senders should always be supported
• It would be nice for one sender to still be a super-optimized use-case

This implies that a Chan should silently get promoted to a SharedChan on a clone(). I believe that this is possible, but I haven't thought through the specific workings in my head just yet.

Another benefit of doing this is reducing the cognitive burden when thinking about channels. We would then be able to fairly easily introduce a BlockingChan (with a better name) which blocks on sends as well as receives. The duality of blocking/nonblocking makes a lot more sense to me than the quadrality of nonblocking/shared nonblocking/blocking/shared blocking.

cc @brson, you made a comment to me awhile ago about doing this.

Nominating, this is backwards compat if we axe SharedChan

[jfager]

Can Chan be a trait? We used to have GenericChan, but that got axed in the last rewrite.

One use case example: https://github.com/jfager/d3cap/blob/master/multicast.rs#L67 - transparently wrapping sends in an enum the reader on the port end knows how to handle but that the sender shouldn't care about.

Not sure if this is sufficiently motivating, and would probably still need the non-blocking vs blocking distinction in the trait spec as the api would of course be different.

[pnkfelix]

Accepted for 1.0, P-backcompat-libs