I don't understand why you think the type of the channel needs to encode information as to whether it's shared. It doesn't encode any other information about how you expect to use the channel. Merging Chan and SharedChan together so users don't even know there's a difference under the hood seems like a good idea to me. Less API to accomplish the same thing == better.
-Kevin On Jan 14, 2014, at 11:06 PM, Eric Reed <ecr...@cs.washington.edu> wrote: > 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 foo<T: 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
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
