On 12/30/2013 08:58 PM, Patrick Walton wrote:
I'm not particularly interested in sacrificing performance by not implementing one or the other in libstd. I think it's clear we need both forms of channels, and they should be first-class primitives.
It's clear there are people who *want* both kinds of channels. It does not follow that they should both be first-class primitives. The possibility of precisely defining the behavior of a bounded channel in all circumstances is what makes it suitable as a first-class primitive. (The other, practical, requirement on primitives is that their number be minimal.) To implement an unbounded channel requires inherently more complex operations -- re-allocations or segmented storage, response to failure -- and corresponding choices that leak consequences visible to users. In an application with extreme constraints on performance, the arbitrary choices that must be taken implementing any particular unbounded-channel design are likely not to match requirements, with the typical result that such an application uses a private re-implementation. In the remaining, less demanding applications, there is no penalty for using an unbounded channel constructed from other, first-class primitives. Nathan Myers _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
