Drive-by mention unsafe fn closure coercion

[alercah]

No description provided.

[ehuss]

I'm a bit uncertain about why it would call out unsafe specifically here. unsafe fn isn't a distinct pointer type from fn is it? I wouldn't expect to call out all the function "front matter" like "extern" here, either.

[alercah]

Yes, they are. Interestingly, though, unsafe closures can be assigned to regular function pointers: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=de1dee0081843286d774d1d21c27091c

(I'm not sure this is wrong, but it's interesting.)

I forgot about extern, but closures can't be converted to extern functions (other than usual Rust ones).

[ldm0]

A drive-by developer here.

@alercah There is no "unsafe closure" actually. For the let u = || unsafe {};, u is just a closure with an unsafe block.

But I think this PR maybe useful. Since the rustc currently support coercing non-capturing closure to safe and unsafe function pointer. Coercing non-capturing closure to extern function pointer may be implemented in the future(rust-lang/rust#44291) but now it won't pass compilation. I guess the reference need to point out either the compile-passing unsafe fn or the non-compile-passing extern fn.

[nikomatsakis]

I do not think of unsafe fn as a distinct type from fn -- rather I think of "function pointers" as types that have a range of options, something like this (ignoring for<...>):

• extern "ABI" unsafe? fn(A0..An) -> R

[alercah]

What about impls?

[nikomatsakis]

@alercah I don't really understand your question, can you elaborate?

[alercah]

I think that the perspective that unsafe fn isn't really a distinct type, and unsafe isbjust a marker, doesn't really hold up when given examples like that you can define trait impls on fn types and unsafe fn types separately. Since this is a reference, I think accuracy should be valued over intuition or pedagogy---not that those things aren't important, but they can't be the first priority.

…

On Wed., Jun. 10, 2020, 09:01 Niko Matsakis, ***@***.***> wrote: @alercah <https://github.com/alercah> I don't really understand your question, can you elaborate? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#802 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE7AOVIM5M45EY5ZMBH27YDRV5733ANCNFSM4MJELWYA> .

[nikomatsakis]

I see. Well, I guess it depends on what one means by "a separate type". I see "function pointer types" as a family of types, I suppose, parameterized by various things:

• their ABI
• their safety
• their argument and return types

much as a type like Vec is parameterized by its element type T.

If we were going for completeness, I don't think that "fn or unsafe fn" is sufficient, since it doesn't account for ABI etc, so perhaps we should just write "(e.g., fn())" instead.

[nikomatsakis]

@alercah

so perhaps we should just write "(e.g., fn())" instead.

what do you think about this? :)

[alercah]

Ah, I see. That makes sense to me!

[nikomatsakis]

in suggestion form

[nikomatsakis]

@ehuss how do I merge, just click the green button? :)

[ehuss]

Yes, after marking "approved" just click the merge button. 😃