[rust-dev] RFC: New Rust channel proposal

Eric Reed ecreed at cs.washington.edu
Tue Jan 14 23:06:17 PST 2014


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 <jack at 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 <ecreed at 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 <ecreed at cs.washington.edu>
> wrote:
> >>
> >> fn foo<T: Trait>() -> T
> >>
> >>
> >> On Tue, Jan 14, 2014 at 9:20 PM, Jack Moffitt <jack at 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 <ecreed at 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 <jack at 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.
> >>> >
> >>> >
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140114/d4a190aa/attachment.html>


More information about the Rust-dev mailing list