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.

Sign up for GitHub

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

Jump to bottom

Tracking issue for enforcing object safety when coercing to an object #17670

Closed
nrc opened this issue Oct 1, 2014 · 10 comments
Closed

Tracking issue for enforcing object safety when coercing to an object #17670

nrc opened this issue Oct 1, 2014 · 10 comments
Assignees
@nrc
Milestone
1.0

Comments

@nrc
Copy link
Member

nrc commented Oct 1, 2014

RFC PR: rust-lang/rfcs#255
@nrc nrc added the I-nominated label Oct 1, 2014
@nrc
Copy link
Member Author

nrc commented Oct 1, 2014

nominating for 1.0, p-backcompat-lang

@nrc nrc self-assigned this Oct 1, 2014
@nrc
Copy link
Member Author

nrc commented Oct 1, 2014

cc @nikomatsakis (assigned to merge the RFC PR)

@nrc
Copy link
Member Author

nrc commented Oct 1, 2014

Note for the future - I expect when we do the DST extension to trait objects we will also need to check here for some properties of associated types - that they don't include generics or Self, probably - not sure how this interacts with binding the associated types in a trait object's type though. I should check the assoc. types RFC...

@nikomatsakis
Copy link
Contributor

I believe that object types must spell out the values of all associated types, at least for now. 

Niko

-------- Original message --------
From: Nick Cameron [email protected]
Date:09/30/2014 23:16 (GMT-05:00)
To: rust-lang/rust [email protected]
Cc: Niko Matsakis [email protected]
Subject: Re: [rust] Tracking issue for enforcing object safety when coercing
to an object (#17670)

Note for the future - I expect when we do the DST extension to trait objects we will also need to check here for some properties of associated types - that they don't include generics or Self, probably - not sure how this interacts with binding the associated types in a trait object's type though. I should check the assoc. types RFC...

—
Reply to this email directly or view it on GitHub.

@nrc nrc mentioned this issue Oct 2, 2014
Closed
@reem
Copy link
Contributor

reem commented Oct 2, 2014

This seems like just a loss in flexibility without us really gaining much. Now we will have to split up traits that used to be simple into many small pieces just to avoid this restriction.

@alexcrichton
Copy link
Member

cc #17704

@pnkfelix
Copy link
Member

pnkfelix commented Oct 2, 2014

(leaving nominated for a week while the debate gets hashed out e.g on PR #17704 )

@pnkfelix
Copy link
Member

pnkfelix commented Oct 9, 2014

leaving nominated until hopefully the weekly meeting next week.

@aturon
Copy link
Member

aturon commented Oct 9, 2014

See http://discuss.rust-lang.org/t/feedback-wanted-trait-objects-with-generic-self-methods/606 and http://www.reddit.com/r/rust/comments/2ihu40/feedback_wanted_trait_objects_with_generic_or/ for discussion. We're going to try to resolve this at the next weekly meeting.

@pnkfelix
Copy link
Member

Assigning 1.0, P-backcompat-lang.

@pnkfelix pnkfelix added this to the 1.0 milestone Oct 16, 2014
nrc added a commit to nrc/rust that referenced this issue Oct 27, 2014
@nrc
Enforce object safety
a4d0929 
closes rust-lang#17670

[breaking-change]

Traits must be object-safe if they are to be used in trait objects. This might require splitting a trait into object-safe and non-object-safe parts.

Some standard library traits in std::io have been split - Reader has new traits BytesReader (for the bytes method) and AsRefReader (for by_ref), Writer has new trait AsRefWriter (for by_ref). All these new traits have blanket impls, so any type which implements Reader or Writer (respectively) will have an implmentation of the new traits. To fix your code, you just need to `use` the new trait.
@nrc nrc closed this as completed in 8d8d8d4 Oct 30, 2014
lnicola pushed a commit to lnicola/rust that referenced this issue Jul 28, 2024
@bors
Auto merge of rust-lang#17670 - Veykril:mem, r=Veykril
be1dc79 
LRU `body_with_source_map` query

This query is being invalidated all the time anyways (we have an extra query on top of it for the body incrementality that is not source dependent), so there is little reason to keep these around all the time when only some IDE features are interested in them.
RalfJung pushed a commit to RalfJung/rust that referenced this issue Aug 1, 2024
@bors
Auto merge of rust-lang#17670 - Veykril:mem, r=Veykril
97a243c 
LRU `body_with_source_map` query

This query is being invalidated all the time anyways (we have an extra query on top of it for the body incrementality that is not source dependent), so there is little reason to keep these around all the time when only some IDE features are interested in them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nrc nrc

Labels
None yet
Projects
None yet
Milestone
1.0
Development

No branches or pull requests
6 participants
@alexcrichton @nikomatsakis @pnkfelix @aturon @nrc @reem