Function pointer lifetimes

[Tobba]

Rendered

(looks like I accidently removed the template by using the github quick commit, be careful)

[emberian]

I think no lifetime should behave just like an reference does. I imagine that there are few if any use cases that need the function pointer to escape.

[eddyb]

@cmr I checked and virtually every use of non-extern fn() as an argument was escaping (by being stored in a structure).
This becomes more clear when you compare closures with non-escaping fn() pointers: you're almost always going to use a closure in those cases.

[Kimundi]

+1, this is the first step to enabling safe dynamic code loading.

[Ericson2314]

Turn fn() into a quasi-unsized type, in such a way that the current fn() would represent &'static fn().

I think that alternative is the way to go. It doesn't commit us to adding more features today, but unlike the status quo and other proposals, it seems way more forwards compatible.

C confuses arrays with pointers, and functions with function pointers. Rust fixed the former, it's high time it addressed the latter.

[eddyb]

@Ericson2314 The big issue with that though is that they are not and cannot be DSTs because they do not support dynamic queries of size and alignment.
That may not seem significant, but it would require duplicating all the DST logic dealing with Sized? and add more kinds to support these "non-sized" types.
That's too much of a language design and implementation cost compared to the original proposal.

[Ericson2314]

@eddyb Would adding length and alignment words before the code ptr work (i.e. [size, align, code....])? If not, won't there be some duplication either way as the RFC as written means a lot of borrowed pointer logic must be duplication?

[eddyb]

@Ericson2314 No, that would not work for, e.g extern "C" fn().
There won't be a duplication of borrowed pointer logic because borrowed pointers are just one type containing a lifetime, all the marker types, trait objects and old closures also have lifetimes and most of the logic is common.

[nikomatsakis]

This RFC has gotten quite old by now, and there are newer RFCs that offer more comprehensive solutions. I'm closing this RFC as postponed under #1037. Thanks very much for the suggestion!