Add {Sender, Receiver}::is_connected

[Thomasdezeeuw]

Checks if the other side of the channel is connected.

Updates #256 (comment)

[Thomasdezeeuw]

The CI failure seems unrelated.

[BurntSushi]

What is the use case for methods like this? They seem inherently problematic to use. At the very least, the docs on these methods should discuss this.

[Thomasdezeeuw]

The use case is I want to know before creating a message if the receiving end is still connected, if not I can avoid doing any work for a message that is never going to be received.

They seem inherently problematic to use.

What do you see as problematic? Of course the method is inherently race-y as the moment the method returns true it could already be false, but its still an optimisation I consider useful.

[BurntSushi]

Its raciness is exactly why I consider it problematic. I don't maintain this library, but I personally wouldn't accept a new API item like this without a reasonable benchmark. If we must have them, the docs should do their best to de-emphasize using this routine and explain their niche use case.

[Thomasdezeeuw]

What do you want to benchmark? If creating a message is expansive, then its always going to be faster to not create a message than creating it and the dropping it (after failing to send it).

[BurntSushi]

That sounds like a micro-benchmark to me. I'd prefer seeing something more holistic.

[Thomasdezeeuw]

Sorry @BurntSushi but I have no idea what you want from me... I asked what you want me to benchmark but you haven't really given an answer to that.

[BurntSushi]

@Thomasdezeeuw I'm not the maintainer of this library. I'm just saying what I personally would like to see because I personally find these APIs to be of somewhat dubious value. Which in turn, to me, means they should be really well motivated before adding them. Namely, I'd like to see a holistic example of a real use case where these sorts of APIs would help. I would probably expect some kind of latency/throughput figures with/without these APIs for example. It may be hard to provide this.

[Thomasdezeeuw]

@stjepang could you take a look at this? In #256 (comment) you mentioned this feature.

[taiki-e]

I don't have a very strong opinion on whether to add this API at this time, but I think it's better to be is_disconnected instead of is_connected. (It matches existing APIs such as error type.)

[Thomasdezeeuw]

@taiki-e I'm ok with changing it, but would that mean this would be considered to be merged?

[taiki-e]

@Thomasdezeeuw I think documentation about what users should be notes of when using this API is needed to merge this PR, not only renaming. FYI: golang/go#20680 and golang/go#30906 have some specific explanations about the problems of similar features.

[Thomasdezeeuw]

This has taken too long and I've moved on to using a different crate.