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

fn should coerce to unsafe fn #1762

Closed
cramertj opened this issue Oct 4, 2016 · 10 comments
Closed

fn should coerce to unsafe fn #1762

cramertj opened this issue Oct 4, 2016 · 10 comments
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.

Comments

@cramertj
Copy link
Member

cramertj commented Oct 4, 2016

Unsafe functions are a strict super-set of safe functions. It seems like fns should freely coerce to the unsafe fn of the appropriate type (i.e. fn() -> () to unsafe fn() -> ()). See this playground link for an example. Is there any particular reason not to allow this?

@petrochenkov
Copy link
Contributor

fn() -> () coerces to unsafe fn() -> () right now. Modified example:

fn print_hello() -> () {
    println!("Hello!");
}

// Calls an unsafe function
fn call_unsafe(func: unsafe fn() -> ()) -> () {
    unsafe { func() }
}

fn main() {
    call_unsafe(print_hello as fn() -> ()); // OK
}

The problem is that print_hello is not a function pointer fn() -> (), but a unique unnameable function type fn() -> () {print_hello} that can be coerced to fn() -> (), so coercion to unsafe fn() -> () actually requires two coercions, and transitive coercions don't work yet, but they are supposed to work eventually.

@KalitaAlexey
Copy link

@petrochenkov Is it hard to add note to mention that as is required to make it?

@cramertj
Copy link
Member Author

cramertj commented Oct 4, 2016

Yeah, I'd at least like to figure out if we can change the compiler error that occurs at the callsite. I never would have thought to cast to fn() -> () in order to get an unsafe fn() -> (), especially since a cast directly to unsafe fn() -> () errors as a non-scalar cast.

@eddyb
Copy link
Member

eddyb commented Oct 4, 2016

@nikomatsakis Should we just allow reification from a safe function to an unsafe fn pointer?

@petrochenkov
Copy link
Contributor

@KalitaAlexey

Is it hard to add note to mention that as is required to make it?

I don't know exactly, but I suspect that simply adding a direct coercion fn() {f} -> unsafe fn() is not harder than adding the note.

@KalitaAlexey
Copy link

@petrochenkov I think this is required some discussion between rust team. I'd like to have it because it doesn't do anything bad.

@nikomatsakis
Copy link
Contributor

@eddyb I think so

@nrc nrc added the T-lang Relevant to the language team, which will review and decide on the RFC. label Oct 4, 2016
@cramertj
Copy link
Member Author

cramertj commented Oct 4, 2016

This is just a matter of combining coerce_from_fn_item and coerce_from_fn_pointer here, right?

@eddyb
Copy link
Member

eddyb commented Oct 4, 2016

@cramertj Sort of, except the safe -> unsafe ptr case would have to also be safe -> safe in coerce_from_fn_item, so combining them might not work out that nicely.

@cramertj
Copy link
Member Author

cramertj commented Oct 4, 2016

Right-- there are three possible end types for a safe fn item, compared to the two that exist currently.

Manishearth added a commit to Manishearth/rust that referenced this issue Oct 26, 2016
…-ptr, r=eddyb

rustc_typeck: Allow reification from fn item to unsafe ptr

See rust-lang/rfcs#1762.

I've never contributed to the compiler internals before-- apologies if I'm not going about this the right way.
bors added a commit to rust-lang/rust that referenced this issue Oct 29, 2016
rustc_typeck: Allow reification from fn item to unsafe ptr

See rust-lang/rfcs#1762.

I've never contributed to the compiler internals before-- apologies if I'm not going about this the right way.
@cramertj cramertj closed this as completed Dec 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

6 participants