Skip to content

/rust

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

remove subtyping relationship for safe/unsafe fns and replace with coercion #23449

Closed
nikomatsakis opened this Issue Mar 17, 2015 · 2 comments

Comments

Assignees

@nikomatsakis nikomatsakis

Labels
None yet
Projects
None yet
Milestone
  1.0 beta
2 participants
@nikomatsakis @rust-highfive
@nikomatsakis
Copy link
Contributor

nikomatsakis commented Mar 17, 2015

Currently, fn is a subtype of unsafe fn. This should be a coercion relationship, pursuant to our strategy of limiting subtyping to region relationships. This also implies that one cannot implement an unsafe trait method with a safe fn, which is useful for solving the "trusted iterator length" problem.
@nikomatsakis

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

nikomatsakis commented Mar 17, 2015

triage: P-backcompat-lang (1.0 beta)

@rust-highfive rust-highfive added the P-backcompat-lang label Mar 17, 2015

@rust-highfive rust-highfive added this to the 1.0 beta milestone Mar 17, 2015

@nikomatsakis

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

nikomatsakis commented Mar 17, 2015

This is not super important, I think we could live with it staying the way it is. But I've got a branch already that seems to be mostly building.

@nikomatsakis nikomatsakis self-assigned this Mar 17, 2015

@nikomatsakis nikomatsakis referenced this issue Mar 17, 2015

Merged

Move fn safety out of the subtyping relationship and into coercions #23452

bors added a commit that referenced this issue Mar 18, 2015

@bors
Auto merge of #23452 - nikomatsakis:unsafety-subtyping, r=nrc 
Safe fns are no longer subtypes of unsafe fns, but you can coerce from one to the other.

This is a [breaking-change] in that impl fns must now be declared `unsafe` if the trait is declared `unsafe`. In some rare cases, the subtyping change may also direct affect you, but no such cases were encountered in practice.

Fixes #23449.

r? @nrc
Loading status checks…
c109189

@bors bors closed this in #23452 Mar 18, 2015

@kennytm kennytm referenced this issue Jan 31, 2018

Open

RFC: Overconstraining and omitting `unsafe` in impls of `unsafe` trait methods #2316

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.