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

Enforce object-safety when coercing to an object #255

Merged
merged 2 commits into from
Oct 16, 2014

Conversation

nrc
Copy link
Member

@nrc nrc commented Sep 22, 2014

Restrict which objects can be coerced to trait objects, rather than which methods can be called on a trait object.

Restrict which objects can be coerced to trait objects, rather than which methods can be called on a trait object.
@nrc nrc self-assigned this Sep 22, 2014
@nrc
Copy link
Member Author

nrc commented Sep 22, 2014

cc @nikomatsakis

@sfackler
Copy link
Member

It would be nice to allow Box<Trait> when Trait has methods that take self by value.

@nrc
Copy link
Member Author

nrc commented Sep 22, 2014

@sfackler do you have an example? I had not considered having different rules for different kinds of trait objects, I fear that would be too much complexity unless there is a really important use case.

@sfackler
Copy link
Member

There's some discussion at rust-lang/rust#10672. Most notably, @pcwalton points out that it's required to allow Box<FnOnce<In, Out>> to replace proc(In) -> Out.

@sfackler
Copy link
Member

It'd also seem to me that you couldn't allow &Trait to implement Trait if it contained any &mut self methods for similar reasons to the by value self case.

@nrc
Copy link
Member Author

nrc commented Sep 22, 2014

@sfackler thanks for the link!

I need to check, but I think that the Box case is OK - fn foo(box self) is ok, it is literally only fn foo(self) which is not.

Why do you think &mut self will cause problems. My thinking here is that the no self by value rule is a kind of hackey way to allow this for 'all' traits rather than traits which are for Sized?. So the only requirement is that we have fat pointers so we have a vtable. Obviously that is not the case for self by value. However, thinking about it, we probably do need the Sized? requirement for Self since otherwise we can dereference self. (Maybe I am missing something on both sides of the argument though).

… rather than restricting value to reference types.
@CloudiDust
Copy link
Contributor

I remember @glaebhoerl arguing that the diffculties around DSTs are signs that we indeed need full-on existential types. I am not sure if this particular problem applies, but here is his (somewhat random) thought about existential types. And I'll leave it here just in case this is relevant. :)

@sfackler
Copy link
Member

Oops, I misinterpreted the proposal wrt &mut self.

@nikomatsakis
Copy link
Contributor

In general, the rules around Self do not apply to the receiver argument. Box<Self> and other such variations definitely need to work.

@nikomatsakis
Copy link
Contributor

Perhaps a more accurate rule would be to say "modified rules around Self apply to the receiver argument". We definitely need to phrase those rules correctly.

@nikomatsakis
Copy link
Contributor

This also intersects the proposed DerefMove trait, I've been working on integrating those two designs. It kind of boils down to a special case of supporting unsized types in parameters, which I still favor.

@reem
Copy link

reem commented Oct 1, 2014

@CloudiDust That's a pretty interesting set of notes. I hadn't thought much about existential types as they apply to Rust, but it seems like it could be a really fantastic fit.

@nikomatsakis nikomatsakis merged commit b4738dd into rust-lang:master Oct 16, 2014
nikomatsakis added a commit that referenced this pull request Oct 16, 2014
milibopp added a commit to milibopp/rust-itertools that referenced this pull request Nov 4, 2014
The introduction of object-safety for coercion to trait objects (see
rust-lang/rfcs#255) affects the previous implementation of BoxIter. It turns
out trait objects are not actually necessary to deal with this situation, so
the implementation was changed to be generic over the type of iterator instead
of the type iterated over.
withoutboats pushed a commit to withoutboats/rfcs that referenced this pull request Jan 15, 2017
@Centril Centril added A-trait-object Proposals relating to trait objects. A-coercions Proposals relating to coercions. A-traits Trait system related proposals & ideas A-typesystem Type system related proposals & ideas A-machine Proposals relating to Rust's abstract machine. labels Nov 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-coercions Proposals relating to coercions. A-machine Proposals relating to Rust's abstract machine. A-trait-object Proposals relating to trait objects. A-traits Trait system related proposals & ideas A-typesystem Type system related proposals & ideas
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants