Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename Send trait to Owned #3542

Closed
brson opened this issue Sep 20, 2012 · 10 comments
Closed

Rename Send trait to Owned #3542

brson opened this issue Sep 20, 2012 · 10 comments
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@brson
Copy link
Contributor

brson commented Sep 20, 2012

The concepts around the core language are much clearer now than when we added the kind system. At the time I was disappointed about including the notion of 'sendability' in the language, while all the actual sending was going on in libraries. Now we have a much better term for sendable things, 'owned', and owning a thing is useful for more than just sending.

If we want we can keep a Send trait that derives from Owned to use in the comms mods. This would require tagging types as Send, which may or may not be desirable. Regardless, Send should be demoted.

Owned 2012.

@brson
Copy link
Contributor Author

brson commented Sep 20, 2012

Also, per @nikomatsakis, the current Owned trait shouldn't exist, represents something other than 'owned' as we usually think of it.

@bblum
Copy link
Contributor

bblum commented Sep 21, 2012

I am somewhat confused by this. As I understand it, today, send means no & pointers and no @ pointers. owned means no & pointers but @ pointers are OK. send precisely describes what's legal to e.g. send over pipes, and owned precisely describes what's legal to store in TLS.

With this change, would we forbid storing @ pointers in TLS (restrictive)? Would we allow storing & pointers in TLS (unsound)? I must be missing something.

@brson
Copy link
Contributor Author

brson commented Sep 21, 2012

The current Owned trait is misnamed.

@bblum
Copy link
Contributor

bblum commented Sep 21, 2012

oh, it will just be renamed also?

@brson
Copy link
Contributor Author

brson commented Sep 21, 2012

@nikomatsakis believes that further refinements to borrowed pointers will make the current Owned trait unnecessary, and that we can rename it to Static or something until.

@nikomatsakis
Copy link
Contributor

I strongly agree with not having const have so many overloaded meanings. To be honest, I think const-the-mutability-qualifier is the odd man out here, and I would like to change it to something else, but I don't know what (read? too valuable to use as a keyword. mut?? looks funny, can't pronounce it. rd or ro? Eh.). I think there is another issue to this effect. I know @jruderman has raised the issue before (and rightly so).

That said, I think Freeze may not be the right name for the trait we currently call Const. Here is my reasoning: a freezable data structure is one which is based purely on owned data and with no explicit mutable qualifiers. This is currently described by Send Const---the Const captures the lack of mutability qualifiers and the Send captures the "relies purely on owned data". So it seems to me that Freeze, if it exists, should be a "subtrait" of Send and Const.

Now, it is not clear to me whether a trait that means "immutable" is necessary on its own. @pcwalton and I have talked about some ideas for removing pure functions and replacing them with closures with a "Const" bound, so it'd be important then. The best name I can come up for to replace Const is Imm (for Immutable, which seems a touch long), even though it is true that an instance of an Imm type, when placed in a mutable local variable (or other mutable context), is in fact mutable. But somehow NoMut doesn't seem to have the same ring!

@bblum
Copy link
Contributor

bblum commented Nov 13, 2012

@nikomatsakis I expect you meant to reply to #3949?

in any case, I wonder: is there any place we use Const where Send is also not used? I'm alluding to the way that Send (no @-pointers) already implies Owned (no &-pointers).

It seems to me we should either (a) make const/send/owned such that each one implies the next (which means Freeze would indeed mean Const Send Owned), or (b) change Send to not imply no &-pointers (whether or not there would ever be a use case for it?) (such that ARCs would require Const Send Owned, not just Const Send).

If there is a use case for Const-without-Send, I favour (b); otherwise, I'm not sure which one I favour.

@nikomatsakis
Copy link
Contributor

@bblum yes, yes I did. :) Regarding uses of Const where Send is not used, that's precisely what I was talking about in the final paragraph---places we might use immutable on its own.

@bblum
Copy link
Contributor

bblum commented Nov 13, 2012

ah, I must have skipped that paragraph. How would the const bound replace purity? (I assume that means something different than the limitation in #3569.)

Immut might be good instead of Imm or Immutable. I might even favour it just as much as Freeze.

@brson
Copy link
Contributor Author

brson commented Dec 14, 2012

Implemented Owned -> Durable, Send -> Owned

@brson brson closed this as completed Dec 14, 2012
RalfJung pushed a commit to RalfJung/rust that referenced this issue May 4, 2024
RalfJung pushed a commit to RalfJung/rust that referenced this issue May 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

3 participants