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

Direct coercion from closures to unsafe fn pointers #57883

Closed
Centril opened this issue Jan 24, 2019 · 2 comments
Closed

Direct coercion from closures to unsafe fn pointers #57883

Centril opened this issue Jan 24, 2019 · 2 comments
Labels
A-coercions Area: implicit and explicit `expr as Type` coercions A-inference Area: Type inference A-typesystem Area: The type system C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@Centril
Copy link
Contributor

Centril commented Jan 24, 2019

While you can coerce closures to fn pointers, it is currently not possible to coerce closures to unsafe fn pointers since that requires a transitive coercion from fn pointers to unsafe fn pointers. We do not allow transitive coercions. Example:

static A: fn() = || {}; // OK
static B: unsafe fn() = A; // OK
static C: unsafe fn() = || {}; // ERROR; would require the two coercions above transitively.

This behavior of current Rust was unexpected in rust-lang/rfcs#2592 (comment).

@cramertj had the idea to implement an immediately attainable direct coercion between closures and unsafe fn pointers rather than go the more complex and contentious route of transitive coercions (which may have unforeseen consequences). This idea seems reasonable to me.

cc @nikomatsakis @arielb1

PS: should we fcp the PR once made?

@Centril Centril added A-typesystem Area: The type system T-lang Relevant to the language team, which will review and decide on the PR/issue. A-inference Area: Type inference A-coercions Area: implicit and explicit `expr as Type` coercions labels Jan 24, 2019
@Centril Centril added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Jan 24, 2019
@cramertj
Copy link
Member

should we fcp

Traditionally we've just accepted PRs for transitive coercions, since they already have a standing RFC. One of these was actually one of my first rustc changes: rust-lang/rfcs#1762

@arielb1
Copy link
Contributor

arielb1 commented Jan 26, 2019

Looks like just a bug, and should be implemented directly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-coercions Area: implicit and explicit `expr as Type` coercions A-inference Area: Type inference A-typesystem Area: The type system C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants