Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upImprove the `fn` pointer types #1037
Comments
nikomatsakis
changed the title
Incorporate lifetimes into function pointers
Improve the `fn` pointer types
Apr 6, 2015
This was referenced Apr 6, 2015
This comment has been minimized.
This comment has been minimized.
|
I am currently of the opinion that if function pointers are not considered pointers by the language, then we'd better call them something else, like "function handles". This can be the first step towards improving "Function pointers are not considered pointers" feels like a flaw in Rust's design, but "function handles are not considered pointers" doesn't. Also, if later "true" function pointers are introduced, we need to disamiguate I wonder if such a renaming proposal should be an RFC? :) |
burdges
referenced this issue
Jan 22, 2016
Closed
Reopen RFCs that were postponed until after 1.0 #1456
Ericson2314
referenced this issue
Jan 5, 2017
Merged
RFC: Allow coercing non-capturing closures to function pointers. #1558
This comment has been minimized.
This comment has been minimized.
wacossusca34
commented
Mar 18, 2017
•
|
We still need a way to specify lifetimes for However, when it comes to DLL loading (see #661), lifetimes of functions that are being used outside of the loaded code will be bound by the lifetime of the library (handle) itself, which the loaded code is unaware of. In this sense, 'static' in all the library code refers to the lifetime of the libray. This means that when symbols are resolved from a DLL, a Additionally, there should be some similar way to specify lifetimes for |
nikomatsakis commentedApr 6, 2015
The current function pointer types have some downsides:
This is a "postponement issue". There have been various RFCs aiming to improve this:
fntypes.fnto&'static fnfor forwards compatibility.It should be possible to adapt these schemes backwards compatibly.