-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
The problem is that |
@petrochenkov Is it hard to add note to mention that |
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 |
@nikomatsakis Should we just allow reification from a safe function to an |
I don't know exactly, but I suspect that simply adding a direct coercion |
@petrochenkov I think this is required some discussion between rust team. I'd like to have it because it doesn't do anything bad. |
@eddyb I think so |
This is just a matter of combining |
@cramertj Sort of, except the safe -> unsafe ptr case would have to also be safe -> safe in |
Right-- there are three possible end types for a safe |
…-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.
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.
Unsafe functions are a strict super-set of safe functions. It seems like
fn
s should freely coerce to theunsafe fn
of the appropriate type (i.e.fn() -> ()
tounsafe fn() -> ()
). See this playground link for an example. Is there any particular reason not to allow this?The text was updated successfully, but these errors were encountered: