Mention that the orderedness of stream/sink to be undefined in the documentation? #2973
Description
Since there is no discussion tab here in this repo, and I don't want to bother opening a thread in the forum, and I just want to say that there is a small little semantic problem with Stream/Sink IMO.
Specifically, given a pair of Stream/Sink, the question of whether it preserves total-orderedness of the trace monoid it forms, is a problem.
More specifically, given that you have a bunch of operations into a bijective, mirrored Stream/Sink pair (which can usually be seen as a channel), let's say R for stream and and W for Sink.
Given that you do W1 then W2 then W3 from the sink write side, it is not known whether from the stream reader side, R1 then R2 then R3 would be guaranteed, it can be R1 then R3 then R2.
I suggest we mention this in the documentation, because it means we cannot use Stream/Sink to express datagram such as UDP or unreliable QUIC, as I'm very much confused why there is no AsyncRead or AsyncWrite for UDP sockets in Tokio. While I found out about Stream and Sink, turns out it is exactly because of this problem so I cannot map it.
A similar analogy would be on the type system of Rust. When you see !Sized, ?Sized or Sized. It can also map to "Must not be Sized", "Maybe Sized" or "Must be sized", or -1, 0 and 1 in balanced ternary logic respectively. Now if we defined a fake trait TotalOrder as well, since we do not know about the whether TotalOrder is a supertrait of Stream, so Stream is implied to be ?TotalOrder, but because UDP is strictly !TotalOrder, therefore I cannot map UDP to Stream operations.
Related: #1293