Re: [rust-dev] RFC: New Rust channel proposal
My biggest gripe with port and channel is that a port can both send and receive things, and a channel is what this things travel along. Also, I believe there is precedent in other languages for source/sink, though that may be only for pipes, which are unrelated to this discussion. Regardless, I agree that source/sink is unintuitive. (Do I take things from the source or put them there as source material for the sink?) Perhaps SendPort and ReceivePort (or RecvPort) would be better names? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
I regularly send/receive things to/from channels at work, and it seems you can do the same with real-world ports. I really have no idea what Rust means by a port does, vs. what it means by a channel, without reading the details in docs. I'd assume the port, channel ordering reads left-to-right like most english, and so equates to send, receive, but that could be a very dangerous assumption. As you can tell from the above, I haven't gotten into using channels yet, or knowing the API in detail, but it's one of the things that attracts me to Rust, so I will eventually. My gut instinct so far, based on limited understanding of what you're trying to represent, is that the API should probably be broken down into clearly distinguished Channels, Connections, and Source/Sink ends to those connections, even if that requires a channel to provide two pairs of sources/sinks for send vs. receive (or just some method which returns these things, swapped around, as a hidden implementation detail). -- Lee On 24/01/14 09:53, Michael Neumann wrote: Am 24.01.2014 04:16, schrieb Strahinja Markovic: On Thu Jan 23 2014 at 3:59:56 PM, Steve Klabnik st...@steveklabnik.com mailto:st...@steveklabnik.com wrote: I don't think that `new` not returning a `Channel` is a big deal. Conceptually, you are, both ends 'make up' a channel. I agree it's not a big deal, but I still think it's something we might want to change. Why introduce a mental speed bump if we don't have to? Foo::new() returns a Foo, Bar::new() returns a Bar, Quux::new() returns a Quux and a Channel::new() returns a... tuple of two items, neither of which is a Channel (I know the two items together are conceptually a /channel/, but they are not a Channel). Using new() here seems like a usability loss for no benefit. But again, it's not a huge issue (should still be fixed though). Port Chan are a bigger problem since users will forever have to double-check which is which or will have to remember it. Why the cognitive load? Channel::new_pipe() returning (Source, Sink) is a usability win we get for free. I am against naming it Source and Sink. It doesn't comply with the verbs we use for sending and receiving, at least for me as a non-native english speaker. While you can get/put something from/to a Source/Sink, you usually don't receive or send from a Source or Sink. The names Port and Channel are ambiguous as well, but at least you can receive (e.g. goods) from a port and send things on a channel. Regards, Michael ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
On 24/01/14 03:54, Brandon Sanderson wrote: I would expect Channel::new() to create a channel object that either lets me send and receive, or lets me get a source and sink to send and receive with. Borrow rules may prevent this, but my point is that Channel::new() would generally be expected to return a struct, and not a tuple. Yes. I think either: * Channel should be a struct, created by Channel::new(), with sender and receiver instances as fields (by whatever name) -- essentially, the tuple should become a struct, with better naming of port and chan * Channel should have a ChannelTrait implemention, with send() and receive(), and should be created by Channel::new() But from what Benjamin says below, it seems like the latter isn't necessary. On Jan 23, 2014 7:29 PM, Benjamin Striegel ben.strie...@gmail.com mailto:ben.strie...@gmail.com wrote: This all seems a bit silly. A channel *is*, conceptually, a tuple of a sender and a receiver. If I call Chan::new(), that's what I expect to get. And Chan::open() doesn't map to anything that's as intuitive. -- Lee ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
On 24/01/14 03:16, Strahinja Markovic wrote: On Thu Jan 23 2014 at 3:59:56 PM, Steve Klabnik st...@steveklabnik.com mailto:st...@steveklabnik.com wrote: I don't think that `new` not returning a `Channel` is a big deal. Conceptually, you are, both ends 'make up' a channel. I agree it's not a big deal, but I still think it's something we might want to change. Why introduce a mental speed bump if we don't have to? Agreed. I think it's VERY weird, even if it's could conceivably work OK for everyone. Why the cognitive load? Channel::new_pipe() returning (Source, Sink) is a usability win we get for free. I know I don't have to convince anyone here just how critical good naming is. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Lee ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
On 24/01/14 13:34, Benjamin Striegel wrote: Anyway, if we've devolving into bikeshedding then it might be time to abandon this thread. Usability isn't something that can be crowdsourced. Well, what you're essentially saying here (assuming you don't mean to disrespect non-core folks by calling them the crowd) is that usability can't be discussed, but of course it can, IF you bear overall principles in mind, rather than devolving into individual instances too much. In this case, the overall usability issues we're TRYING to communicate are: 1)X::new() should return an X 2)An X should do what it sounds like it does -- Lee ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
On 01/13/2014 10:15 PM, Liigo Zhuang wrote: People should rethink the Chan api that Chan::new() does not returns a value of type Chan (instead, a tuple), which is strange, and inconsistent with other Type::new(). Agree, though I haven't heard any great suggestions yet. The core problem is that there are three different entities involved: the sending end, the recieving end, and the thing that represents the entire channel, and they all need different names. The best I've heard is `pipe() - (Port, Chan)`, but I would rather call the whole thing a channel and have a different name for the sender. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
On Thu, Jan 23, 2014 at 2:33 PM, Brian Anderson bander...@mozilla.comwrote: On 01/13/2014 10:15 PM, Liigo Zhuang wrote: People should rethink the Chan api that Chan::new() does not returns a value of type Chan (instead, a tuple), which is strange, and inconsistent with other Type::new(). Agree, though I haven't heard any great suggestions yet. The core problem is that there are three different entities involved: the sending end, the recieving end, and the thing that represents the entire channel, and they all need different names. The best I've heard is `pipe() - (Port, Chan)`, but I would rather call the whole thing a channel and have a different name for the sender. A good alias / synonym for a sender would be a transmitter. food for thought. -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
Maybe we can borrow some inspiration from the haskell pipes library? On Thu, Jan 23, 2014 at 2:32 PM, Vadim vadi...@gmail.com wrote: Well maybe then channel() - (SendEnd, RecvEnd) ? Or, channel() - (Source, Drain) ? On Thu, Jan 23, 2014 at 12:33 PM, Brian Anderson bander...@mozilla.comwrote: On 01/13/2014 10:15 PM, Liigo Zhuang wrote: People should rethink the Chan api that Chan::new() does not returns a value of type Chan (instead, a tuple), which is strange, and inconsistent with other Type::new(). Agree, though I haven't heard any great suggestions yet. The core problem is that there are three different entities involved: the sending end, the recieving end, and the thing that represents the entire channel, and they all need different names. The best I've heard is `pipe() - (Port, Chan)`, but I would rather call the whole thing a channel and have a different name for the sender. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
I don't think that `new` not returning a `Channel` is a big deal. Conceptually, you are, both ends 'make up' a channel. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
I would expect Channel::new() to create a channel object that either lets me send and receive, or lets me get a source and sink to send and receive with. Borrow rules may prevent this, but my point is that Channel::new() would generally be expected to return a struct, and not a tuple. On Jan 23, 2014 7:29 PM, Benjamin Striegel ben.strie...@gmail.com wrote: This all seems a bit silly. A channel *is*, conceptually, a tuple of a sender and a receiver. If I call Chan::new(), that's what I expect to get. And Chan::open() doesn't map to anything that's as intuitive. Is naming really all that's left to argue about? How does everyone feel about the semantics of the proposal? On Thu, Jan 23, 2014 at 10:20 PM, Strahinja Markovic v...@markovic.iowrote: On Thu Jan 23 2014 at 7:18:11 PM, Tony Arcieri basc...@gmail.com wrote: I have a crazy idea... Channel::open() That's a better name for the function, agreed. https://lh3.ggpht.com/-WpuYGqCEHDg/UBznzaqReKI/B_0/0Vc8_mnnhqw/s1600/mind-blown.gif -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
Also, +1 for source and sink, I still get port and channel mixed up. On Thursday, January 23, 2014, Jason Fager jfa...@gmail.com wrote: open() feels like the clear winner here. Channel::new_pipe is annoying because it's long and because channels and pipes are different things ( http://en.m.wikipedia.org/wiki/Pipe_flow), And aren't we down to naming? I thought the design sounded mostly settled from the last conversation, and brson revived the thread specifically responding to a question about naming. On Thursday, January 23, 2014, Tony Arcieri basc...@gmail.com wrote: On Thu, Jan 23, 2014 at 7:29 PM, Benjamin Striegel ben.strie...@gmail.com wrote: And Chan::open() doesn't map to anything that's as intuitive. Like File::open? :P -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
Hi, as a not contributing listen-in, i would like to voice that source and sink share the same initial and therefore source and drain might be more useful. I hope i didn't offend by voicing my opinion, keep up the good work! Regards Don Am 24.01.2014 04:54, schrieb Brandon Sanderson: I would expect Channel::new() to create a channel object that either lets me send and receive, or lets me get a source and sink to send and receive with. Borrow rules may prevent this, but my point is that Channel::new() would generally be expected to return a struct, and not a tuple. On Jan 23, 2014 7:29 PM, Benjamin Striegel ben.strie...@gmail.com mailto:ben.strie...@gmail.com wrote: This all seems a bit silly. A channel *is*, conceptually, a tuple of a sender and a receiver. If I call Chan::new(), that's what I expect to get. And Chan::open() doesn't map to anything that's as intuitive. Is naming really all that's left to argue about? How does everyone feel about the semantics of the proposal? On Thu, Jan 23, 2014 at 10:20 PM, Strahinja Markovic v...@markovic.io mailto:v...@markovic.io wrote: On Thu Jan 23 2014 at 7:18:11 PM, Tony Arcieri basc...@gmail.com mailto:basc...@gmail.com wrote: I have a crazy idea... Channel::open() That's a better name for the function, agreed. https://lh3.ggpht.com/-WpuYGqCEHDg/UBznzaqReKI/B_0/0Vc8_mnnhqw/s1600/mind-blown.gif -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
If we're going to quibble over names we might as well call the types Sender and Receiver. Really though, EVERYONE is fine with the proposed semantics from the original thread? Really? Speak up if you have anything valuable to add that isn't bikeshedding! :) On Thu, Jan 23, 2014 at 11:13 PM, don donquest...@rocketmail.com wrote: Hi, as a not contributing listen-in, i would like to voice that source and sink share the same initial and therefore source and drain might be more useful. I hope i didn't offend by voicing my opinion, keep up the good work! Regards Don Am 24.01.2014 04:54, schrieb Brandon Sanderson: I would expect Channel::new() to create a channel object that either lets me send and receive, or lets me get a source and sink to send and receive with. Borrow rules may prevent this, but my point is that Channel::new() would generally be expected to return a struct, and not a tuple. On Jan 23, 2014 7:29 PM, Benjamin Striegel ben.strie...@gmail.com mailto:ben.strie...@gmail.com wrote: This all seems a bit silly. A channel *is*, conceptually, a tuple of a sender and a receiver. If I call Chan::new(), that's what I expect to get. And Chan::open() doesn't map to anything that's as intuitive. Is naming really all that's left to argue about? How does everyone feel about the semantics of the proposal? On Thu, Jan 23, 2014 at 10:20 PM, Strahinja Markovic v...@markovic.io mailto:v...@markovic.io wrote: On Thu Jan 23 2014 at 7:18:11 PM, Tony Arcieri basc...@gmail.com mailto:basc...@gmail.com wrote: I have a crazy idea... Channel::open() That's a better name for the function, agreed. https://lh3.ggpht.com/-WpuYGqCEHDg/UBznzaqReKI/ B_0/0Vc8_mnnhqw/s1600/mind-blown.gif -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
On Thu, Jan 23, 2014 at 8:55 PM, Benjamin Striegel ben.strie...@gmail.comwrote: If we're going to quibble over names we might as well call the types Sender and Receiver. +1 on that Really though, EVERYONE is fine with the proposed semantics from the original thread? Really? Speak up if you have anything valuable to add that isn't bikeshedding! :) As probably the primary instigator of this change, I'd just like to say you've done a great job resolving my original complaints, thanks ;) -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
My vote, FWIW let (sender, receiver) = Chan::open(); -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
I've opened an issue on the naming problem https://github.com/mozilla/rust/issues/11765 On 01/23/2014 08:55 PM, Benjamin Striegel wrote: If we're going to quibble over names we might as well call the types Sender and Receiver. Really though, EVERYONE is fine with the proposed semantics from the original thread? Really? Speak up if you have anything valuable to add that isn't bikeshedding! :) On Thu, Jan 23, 2014 at 11:13 PM, don donquest...@rocketmail.com mailto:donquest...@rocketmail.com wrote: Hi, as a not contributing listen-in, i would like to voice that source and sink share the same initial and therefore source and drain might be more useful. I hope i didn't offend by voicing my opinion, keep up the good work! Regards Don Am 24.01.2014 04:54, schrieb Brandon Sanderson: I would expect Channel::new() to create a channel object that either lets me send and receive, or lets me get a source and sink to send and receive with. Borrow rules may prevent this, but my point is that Channel::new() would generally be expected to return a struct, and not a tuple. On Jan 23, 2014 7:29 PM, Benjamin Striegel ben.strie...@gmail.com mailto:ben.strie...@gmail.com mailto:ben.strie...@gmail.com mailto:ben.strie...@gmail.com wrote: This all seems a bit silly. A channel *is*, conceptually, a tuple of a sender and a receiver. If I call Chan::new(), that's what I expect to get. And Chan::open() doesn't map to anything that's as intuitive. Is naming really all that's left to argue about? How does everyone feel about the semantics of the proposal? On Thu, Jan 23, 2014 at 10:20 PM, Strahinja Markovic v...@markovic.io mailto:v...@markovic.io mailto:v...@markovic.io mailto:v...@markovic.io wrote: On Thu Jan 23 2014 at 7:18:11 PM, Tony Arcieri basc...@gmail.com mailto:basc...@gmail.com mailto:basc...@gmail.com mailto:basc...@gmail.com wrote: I have a crazy idea... Channel::open() That's a better name for the function, agreed. https://lh3.ggpht.com/-WpuYGqCEHDg/UBznzaqReKI/B_0/0Vc8_mnnhqw/s1600/mind-blown.gif -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
On Mon, Jan 13, 2014 at 6:48 PM, Brian Anderson bander...@mozilla.comwrote: Let's add `SyncChan` which is a bounded multi-producer single-consumer queue backed by a ring buffer. This supports `send`, which blocks by default, and `try_send` which returns an enum representing whether the send succeeded, the channel is full, or the channel is closed (the last two cases returning the message). In the special case where the channel bound is 0, we don't use a ringbuffer and just do a rendezvousing send and recieve. The default bound is 0. Nice! This sounds awesome. -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
How would that make us lose stack allocated return values? On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt j...@metajack.im wrote: Good point. Make `Chan` a trait with implementers `UniqueChan` and `SharedChan`? I suppose the main downside of that solution is that you lose stack allocated return values. jack. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
You can't do `foo() - Trait`. It would have to be `foo() - ~Trait`. Well, unless DST fixes this. I assume this is the same reason we return specific instances of iterators instead of an Iteratable trait object. jack. On Tue, Jan 14, 2014 at 10:10 PM, Eric Reed ecr...@cs.washington.edu wrote: How would that make us lose stack allocated return values? On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt j...@metajack.im wrote: Good point. Make `Chan` a trait with implementers `UniqueChan` and `SharedChan`? I suppose the main downside of that solution is that you lose stack allocated return values. jack. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
fn fooT: Trait() - T On Tue, Jan 14, 2014 at 9:20 PM, Jack Moffitt j...@metajack.im wrote: You can't do `foo() - Trait`. It would have to be `foo() - ~Trait`. Well, unless DST fixes this. I assume this is the same reason we return specific instances of iterators instead of an Iteratable trait object. jack. On Tue, Jan 14, 2014 at 10:10 PM, Eric Reed ecr...@cs.washington.edu wrote: How would that make us lose stack allocated return values? On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt j...@metajack.im wrote: Good point. Make `Chan` a trait with implementers `UniqueChan` and `SharedChan`? I suppose the main downside of that solution is that you lose stack allocated return values. jack. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
As a follow up, what situation would arise where you'd have to actually return a Chan trait object? Constructors are going to return the concrete type UniqueChan/SharedChan. Functions acting on channels can just use generics, which will allow returning. On Tue, Jan 14, 2014 at 9:21 PM, Eric Reed ecr...@cs.washington.edu wrote: fn fooT: Trait() - T On Tue, Jan 14, 2014 at 9:20 PM, Jack Moffitt j...@metajack.im wrote: You can't do `foo() - Trait`. It would have to be `foo() - ~Trait`. Well, unless DST fixes this. I assume this is the same reason we return specific instances of iterators instead of an Iteratable trait object. jack. On Tue, Jan 14, 2014 at 10:10 PM, Eric Reed ecr...@cs.washington.edu wrote: How would that make us lose stack allocated return values? On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt j...@metajack.im wrote: Good point. Make `Chan` a trait with implementers `UniqueChan` and `SharedChan`? I suppose the main downside of that solution is that you lose stack allocated return values. jack. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: New Rust channel proposal
I was working under the assumption that we'd add UniqueChan - SharedChan promotion back. I assumed that would be possible since a unified Chan would be doing it internally. Does an auto-promoting Chan really do that much for reducing cognitive load? The only thing the programmer can skip understanding with a unified Chan is the whether to choose between cloneable and uncloneable channels, which isn't very much. It seems like a pretty significant departure from how Rust approaches this kind of thing elsewhere (i.e. memory allocation and threading model being the two things that come to mind). I'm just skeptical that the cognitive load reduction outweighs the information loss. On Tue, Jan 14, 2014 at 9:41 PM, Jack Moffitt j...@metajack.im wrote: You can't promote a Chan to a SharedChan currently (like you could with the old API), so if the caller needs to make the decision, all the APIs will have to return SharedChan to be flexible. I don't think traits help with that problem (they do help with passing in Chans). If we want flexible APIs that returns Chans, we need promotion of some kind. I think I misspoke before. The core issue is cognitive load of 3 channel types. Auto-promoting Chan to shared Chan reduces the number of channels (less API surface) and makes channels just work (never have to think about whether Chans are clonable). That seems a compelling combo. I was just focused more on the latter use case. jack. On Tue, Jan 14, 2014 at 10:26 PM, Eric Reed ecr...@cs.washington.edu wrote: As a follow up, what situation would arise where you'd have to actually return a Chan trait object? Constructors are going to return the concrete type UniqueChan/SharedChan. Functions acting on channels can just use generics, which will allow returning. On Tue, Jan 14, 2014 at 9:21 PM, Eric Reed ecr...@cs.washington.edu wrote: fn fooT: Trait() - T On Tue, Jan 14, 2014 at 9:20 PM, Jack Moffitt j...@metajack.im wrote: You can't do `foo() - Trait`. It would have to be `foo() - ~Trait`. Well, unless DST fixes this. I assume this is the same reason we return specific instances of iterators instead of an Iteratable trait object. jack. On Tue, Jan 14, 2014 at 10:10 PM, Eric Reed ecr...@cs.washington.edu wrote: How would that make us lose stack allocated return values? On Tue, Jan 14, 2014 at 5:22 PM, Jack Moffitt j...@metajack.im wrote: Good point. Make `Chan` a trait with implementers `UniqueChan` and `SharedChan`? I suppose the main downside of that solution is that you lose stack allocated return values. jack. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
