From d7137247a7854c9be2886145af25811b06ca8e3f Mon Sep 17 00:00:00 2001 From: John Ericson Date: Tue, 17 Feb 2015 14:23:30 -0500 Subject: [PATCH 01/12] First draft of fun ptr rfc --- text/0000-fun-vs-fun-ptr.md | 79 +++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 text/0000-fun-vs-fun-ptr.md diff --git a/text/0000-fun-vs-fun-ptr.md b/text/0000-fun-vs-fun-ptr.md new file mode 100644 index 00000000000..d196f771f23 --- /dev/null +++ b/text/0000-fun-vs-fun-ptr.md @@ -0,0 +1,79 @@ +- Feature Name: explicit_fun_ptr +- Start Date: 2015-2-17 +- RFC PR: (leave this empty) +- Rust Issue: (leave this empty) + +# Summary + +For clarity and safety, it is likely that Rust will want to someday distinguish between functions +and function pointers[1]. It is tempting to use DST for this, but unfortunately that would make +function pointers fat, and moreover the sizes of functions are not in-general known dynamically +anyway (c.f. foreign functions). Thus, this RFC instead proposals a slight syntactic disambiguation +that should be much more forwards compatible with future work in this area post-1.0. + +# Motivation + +Currently, functions are treated like statics, and function pointers like `&'static`s. This fits +common case where all functions are either statically linked or dynamic linked in a transparent +fashion. + +When more manually invoking the loader or JIT-compiling, however, these restrictions no longer fit +as function are dynamically creatable and destroyable like any value of a "normal" type. As such, it +would be nice to have all the machinery Rust offers (lifetimes, ownership, etc) for keeping track of +values of normal types available for values of function pointer types. + +Implementing all these things for functions will mean much more decision making and implementation +effort than is feasable for the pre-1.0 timeframe. What we can do now is change the syntax of +function pointer types to make clear they really are `&'statics`. This will syntactically "make way" +for the other function pointer types to be added in the future, and make Rust more forthright about +its current expressiveness. + +# Detailed design + +Quite simply change the syntax of function pointer types from + +```rust + +fn(...) ... +``` + +to + +```rust + +&'static fn(...) ... +``` + +Like slices before DST, the `fn(...) ...` itself will not denote a type on its own and need not even +parse. It can be made legal syntax and given semantics in the future. + +Just as today, function items may have unique function types, but those types won't have a surface +syntax, and expressions (in practice just identifiers/paths) of those types will coerce to function +pointers (see [1]). + +# Drawbacks + + - Temporary ergonomic loss + - May not extend language with borrowed function pointers in the future + - All non-static functions can only be created in unsafe ways, so this is just making a safe + interface to fake at the end of the day. + - But even if the function itself may not conform to the type, at least the backing executable + memory could potentially be managed 100% safely. + +# Alternatives + + - Seeing that in the short-term, all functions will have a static lifetime (i. e. can only cast a + value to a function pointer and not a function). It might be perfectly safe to allow `&fn(...) + ...` with the normal lifetime inference rules. + + - The above isn't true, but the lifetime inference could special-case-default to `static` with a + function pointer type. (Yuck!) + + - `fn (...):'a ...` syntax. + +# Unresolved questions + +Perhaps I am mistaken and the semantics of `&'statics` and functions pointers differ. + +[1]: https://github.com/rust-lang/rust/pull/19891 The implementation currently distinguishes between + function types and function pointer types, but this is not really exposed as part of the language. From dadbe9e209748e26801145f17e740f3ea7ee5bca Mon Sep 17 00:00:00 2001 From: John Ericson Date: Tue, 17 Feb 2015 15:47:46 -0500 Subject: [PATCH 02/12] Some tweaks and clarifications --- text/0000-fun-vs-fun-ptr.md | 36 +++++++++++++++++++++--------------- 1 file changed, 21 insertions(+), 15 deletions(-) diff --git a/text/0000-fun-vs-fun-ptr.md b/text/0000-fun-vs-fun-ptr.md index d196f771f23..fe0de44de51 100644 --- a/text/0000-fun-vs-fun-ptr.md +++ b/text/0000-fun-vs-fun-ptr.md @@ -13,20 +13,20 @@ that should be much more forwards compatible with future work in this area post- # Motivation -Currently, functions are treated like statics, and function pointers like `&'static`s. This fits +Currently, functions have statics lifetimes, and function pointers act like `&'static`s. This fits common case where all functions are either statically linked or dynamic linked in a transparent fashion. -When more manually invoking the loader or JIT-compiling, however, these restrictions no longer fit -as function are dynamically creatable and destroyable like any value of a "normal" type. As such, it -would be nice to have all the machinery Rust offers (lifetimes, ownership, etc) for keeping track of -values of normal types available for values of function pointer types. +When more manually invoking the loader or JIT-compiling, however, functions with non-static +lifetimes arise as function are dynamically creatable and destroyable like any value of a "normal" +type. As such, it would be nice to have all the machinery Rust offers (lifetimes, ownership, etc) +available for functions too. Implementing all these things for functions will mean much more decision making and implementation -effort than is feasable for the pre-1.0 timeframe. What we can do now is change the syntax of -function pointer types to make clear they really are `&'statics`. This will syntactically "make way" -for the other function pointer types to be added in the future, and make Rust more forthright about -its current expressiveness. +effort than is feasible for the pre-1.0 timeframe. What we can do now is change the syntax of +function pointer types to make clear they act like `&'statics`. This allow them to silently become +actual `&statics` if function types are added in the future, and make Rust more forthright about its +current expressiveness today. # Detailed design @@ -45,7 +45,11 @@ to ``` Like slices before DST, the `fn(...) ...` itself will not denote a type on its own and need not even -parse. It can be made legal syntax and given semantics in the future. +parse. + +In the future, `fn(...) ...` can be made legal syntax and given semantics, in which case the current +syntax would no longer be its own grammatical production but remain valid, and actually denote the +type of a static, immutable borrowed pointer to a function. Just as today, function items may have unique function types, but those types won't have a surface syntax, and expressions (in practice just identifiers/paths) of those types will coerce to function @@ -62,18 +66,20 @@ pointers (see [1]). # Alternatives - - Seeing that in the short-term, all functions will have a static lifetime (i. e. can only cast a - value to a function pointer and not a function). It might be perfectly safe to allow `&fn(...) - ...` with the normal lifetime inference rules. + - Seeing that in the short-term, all functions will have a static lifetime (i. e. can only + transmute a value to a function pointer and not a function). It might be perfectly safe to allow + `&fn(...) ...` with the normal lifetime inference rules. I hope this is the case, but as it + relies on more assumptions I put it as an alternative to stay safe. - The above isn't true, but the lifetime inference could special-case-default to `static` with a function pointer type. (Yuck!) - - `fn (...):'a ...` syntax. + - `fn (...):'a ...` syntax. This would seem to doom us to a redundancy with borrowed pointers in + the future rather than prevent it. I believe it was rejected before too. # Unresolved questions -Perhaps I am mistaken and the semantics of `&'statics` and functions pointers differ. +Perhaps I am mistaken and the semantics of `&'static`s and functions pointers differ. [1]: https://github.com/rust-lang/rust/pull/19891 The implementation currently distinguishes between function types and function pointer types, but this is not really exposed as part of the language. From 109f1b604532939ac8d614e136d2547f3349b4fd Mon Sep 17 00:00:00 2001 From: John Ericson Date: Tue, 17 Feb 2015 17:27:06 -0500 Subject: [PATCH 03/12] Expand on motivation --- text/0000-fun-vs-fun-ptr.md | 42 +++++++++++++++++++++++++++---------- 1 file changed, 31 insertions(+), 11 deletions(-) diff --git a/text/0000-fun-vs-fun-ptr.md b/text/0000-fun-vs-fun-ptr.md index fe0de44de51..690650f8574 100644 --- a/text/0000-fun-vs-fun-ptr.md +++ b/text/0000-fun-vs-fun-ptr.md @@ -5,11 +5,12 @@ # Summary -For clarity and safety, it is likely that Rust will want to someday distinguish between functions -and function pointers[1]. It is tempting to use DST for this, but unfortunately that would make -function pointers fat, and moreover the sizes of functions are not in-general known dynamically -anyway (c.f. foreign functions). Thus, this RFC instead proposals a slight syntactic disambiguation -that should be much more forwards compatible with future work in this area post-1.0. +It is likely that Rust will want to someday have a notion of an unboxed function type to be used +with custom pointer types[1]. Ideally then today's function pointers would become `&'static`s of +functions. But this is a braking syntactic change, and unboxed functions can probably not be exposed +by 1.0. This RFC proposals making the needed breaking syntactic change now, so unboxed functions can +be added---and function pointers turned to borrowed pointers---all backwards compatibly in the +future. # Motivation @@ -22,15 +23,34 @@ lifetimes arise as function are dynamically creatable and destroyable like any v type. As such, it would be nice to have all the machinery Rust offers (lifetimes, ownership, etc) available for functions too. -Implementing all these things for functions will mean much more decision making and implementation -effort than is feasible for the pre-1.0 timeframe. What we can do now is change the syntax of -function pointer types to make clear they act like `&'statics`. This allow them to silently become -actual `&statics` if function types are added in the future, and make Rust more forthright about its -current expressiveness today. +A nice way to enable all that machinery is add actual "unboxed" function types, unlike the +function-ptr types that currently exist. That ways the whole menagerie of parameterized pointer +types are available for use with functions to generate many types of function pointers. To give some +examples of the possibilities, `Arc` can be used ARC to unload libraries or free JITed code, or, as +@eddyb came up with, (unsafe to deref) `*const` pointers to functions could replace unsafe function +pointers. + +Adding unboxed function types begs the questions of what would happen to the current function +pointers where that route taken. Since they act just like immutable borrowed static pointers to +functions, it would be nice if they became that in actuality, lest two ways to do the same thing be +introduced so deeply in the language. Unfortunately, combining the two requires a braking syntactic +change. There are many details that need to be resolved to support unboxed function types, plus +probably a good deal of implementation work, so it is probably not realistic to try to do this +before 1.0. Note, while it is tempting to use DST for this, but unfortunately that would make +function pointers fat, and moreover the sizes of functions are not in-general known dynamically +anyway (c.f. foreign functions). + +So if this requires a breaking change to make nice, yet is to big to do before 1.0, what can be +done? My suggestion is simply to simply change the syntax of function pointer types to make clear +they act like `&'statics`. This doesn't force any semantic changes in the future, but opens to door +to reusing `fn(...)...` for unboxed functions by allowing function pointers to silently become +actual `&statics` if/when function types are added in the future. Meanwhile Rust, while slightly +less ergonomic---function pointers are quite rare, is more forthright about its current +expressiveness today. # Detailed design -Quite simply change the syntax of function pointer types from +Quite simply, change the syntax of function pointer types from ```rust From 6c6df2e5315a9f81b60cb547087f573a9dc4e9b0 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Tue, 17 Feb 2015 17:29:43 -0500 Subject: [PATCH 04/12] Remove two unintended blank lines --- text/0000-fun-vs-fun-ptr.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/text/0000-fun-vs-fun-ptr.md b/text/0000-fun-vs-fun-ptr.md index 690650f8574..339af630790 100644 --- a/text/0000-fun-vs-fun-ptr.md +++ b/text/0000-fun-vs-fun-ptr.md @@ -53,14 +53,12 @@ expressiveness today. Quite simply, change the syntax of function pointer types from ```rust - fn(...) ... ``` to ```rust - &'static fn(...) ... ``` From e0f7b16ae6e024929867dbaf1360a251311a44c0 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Tue, 17 Feb 2015 17:38:09 -0500 Subject: [PATCH 05/12] Reference @Tobba's pre-RFC --- text/0000-fun-vs-fun-ptr.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0000-fun-vs-fun-ptr.md b/text/0000-fun-vs-fun-ptr.md index 339af630790..7ca105bc03b 100644 --- a/text/0000-fun-vs-fun-ptr.md +++ b/text/0000-fun-vs-fun-ptr.md @@ -93,7 +93,8 @@ pointers (see [1]). function pointer type. (Yuck!) - `fn (...):'a ...` syntax. This would seem to doom us to a redundancy with borrowed pointers in - the future rather than prevent it. I believe it was rejected before too. + the future rather than prevent it, thought it does give us more expressiveness. Pre-RFC for this + at http://internals.rust-lang.org/t/pre-rfc-fn-lifetimes/472 . # Unresolved questions From b002e10a0d93aa371e2f88a8b37a2989b179a8b9 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Tue, 17 Feb 2015 19:29:33 -0500 Subject: [PATCH 06/12] typo: braking -> breaking --- text/0000-fun-vs-fun-ptr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-fun-vs-fun-ptr.md b/text/0000-fun-vs-fun-ptr.md index 7ca105bc03b..6bd1d01b87e 100644 --- a/text/0000-fun-vs-fun-ptr.md +++ b/text/0000-fun-vs-fun-ptr.md @@ -7,7 +7,7 @@ It is likely that Rust will want to someday have a notion of an unboxed function type to be used with custom pointer types[1]. Ideally then today's function pointers would become `&'static`s of -functions. But this is a braking syntactic change, and unboxed functions can probably not be exposed +functions. But this is a breaking syntactic change, and unboxed functions can probably not be exposed by 1.0. This RFC proposals making the needed breaking syntactic change now, so unboxed functions can be added---and function pointers turned to borrowed pointers---all backwards compatibly in the future. From c004559bc6504cb80a4801c0277353a77fb69691 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 19 Feb 2015 16:54:38 -0500 Subject: [PATCH 07/12] Fix typos. Thank you @glaebhoerl ! --- text/0000-fun-vs-fun-ptr.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-fun-vs-fun-ptr.md b/text/0000-fun-vs-fun-ptr.md index 6bd1d01b87e..d1550f8774f 100644 --- a/text/0000-fun-vs-fun-ptr.md +++ b/text/0000-fun-vs-fun-ptr.md @@ -31,16 +31,16 @@ examples of the possibilities, `Arc` can be used ARC to unload libraries or free pointers. Adding unboxed function types begs the questions of what would happen to the current function -pointers where that route taken. Since they act just like immutable borrowed static pointers to +pointers were that route taken. Since they act just like immutable borrowed static pointers to functions, it would be nice if they became that in actuality, lest two ways to do the same thing be -introduced so deeply in the language. Unfortunately, combining the two requires a braking syntactic +introduced so deeply in the language. Unfortunately, combining the two requires a breaking syntactic change. There are many details that need to be resolved to support unboxed function types, plus probably a good deal of implementation work, so it is probably not realistic to try to do this before 1.0. Note, while it is tempting to use DST for this, but unfortunately that would make function pointers fat, and moreover the sizes of functions are not in-general known dynamically anyway (c.f. foreign functions). -So if this requires a breaking change to make nice, yet is to big to do before 1.0, what can be +So if this requires a breaking change to make nice, yet is too big to do before 1.0, what can be done? My suggestion is simply to simply change the syntax of function pointer types to make clear they act like `&'statics`. This doesn't force any semantic changes in the future, but opens to door to reusing `fn(...)...` for unboxed functions by allowing function pointers to silently become From a9e98cea348b1f542d7c127ba4ed7f2cbe83bd55 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 19 Feb 2015 17:39:34 -0500 Subject: [PATCH 08/12] Nicer footnote --- text/0000-fun-vs-fun-ptr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-fun-vs-fun-ptr.md b/text/0000-fun-vs-fun-ptr.md index d1550f8774f..a225f0b9f0c 100644 --- a/text/0000-fun-vs-fun-ptr.md +++ b/text/0000-fun-vs-fun-ptr.md @@ -6,7 +6,7 @@ # Summary It is likely that Rust will want to someday have a notion of an unboxed function type to be used -with custom pointer types[1]. Ideally then today's function pointers would become `&'static`s of +with custom pointer types1. Ideally then today's function pointers would become `&'static`s of functions. But this is a breaking syntactic change, and unboxed functions can probably not be exposed by 1.0. This RFC proposals making the needed breaking syntactic change now, so unboxed functions can be added---and function pointers turned to borrowed pointers---all backwards compatibly in the From 947b9982814edef1fa4382abdba613dca32ffbe6 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 19 Feb 2015 17:41:13 -0500 Subject: [PATCH 09/12] Footnote after period --- text/0000-fun-vs-fun-ptr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-fun-vs-fun-ptr.md b/text/0000-fun-vs-fun-ptr.md index a225f0b9f0c..6ada8cf7c6c 100644 --- a/text/0000-fun-vs-fun-ptr.md +++ b/text/0000-fun-vs-fun-ptr.md @@ -6,7 +6,7 @@ # Summary It is likely that Rust will want to someday have a notion of an unboxed function type to be used -with custom pointer types1. Ideally then today's function pointers would become `&'static`s of +with custom pointer types.1 Ideally then today's function pointers would become `&'static`s of functions. But this is a breaking syntactic change, and unboxed functions can probably not be exposed by 1.0. This RFC proposals making the needed breaking syntactic change now, so unboxed functions can be added---and function pointers turned to borrowed pointers---all backwards compatibly in the From dc1044f39cced35a3c91e93c475bdecbc2e54438 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Sun, 22 Feb 2015 14:22:43 -0500 Subject: [PATCH 10/12] Make grammars more formal --- text/0000-fun-vs-fun-ptr.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-fun-vs-fun-ptr.md b/text/0000-fun-vs-fun-ptr.md index 6ada8cf7c6c..d6618aa0c36 100644 --- a/text/0000-fun-vs-fun-ptr.md +++ b/text/0000-fun-vs-fun-ptr.md @@ -53,13 +53,13 @@ expressiveness today. Quite simply, change the syntax of function pointer types from ```rust -fn(...) ... +('extern' STRING_LIT?)? 'fn' '(' (IDEN ':' TYPE (',' IDEN ':' TYPE)* ','?)? ')' ('->' TYPE)? ``` to ```rust -&'static fn(...) ... +'&' '\'static' ('extern' STRING_LIT?)? 'fn' '(' (IDEN ':' TYPE (',' IDEN ':' TYPE)* ','?)? ')' ('->' TYPE)? ``` Like slices before DST, the `fn(...) ...` itself will not denote a type on its own and need not even From c7123236bdf9630ca4a5a246516d107c83646a06 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Sun, 22 Feb 2015 15:15:18 -0500 Subject: [PATCH 11/12] Propose @P1start's coercision rules --- text/0000-fun-vs-fun-ptr.md | 60 ++++++++++++++++++++----------------- 1 file changed, 33 insertions(+), 27 deletions(-) diff --git a/text/0000-fun-vs-fun-ptr.md b/text/0000-fun-vs-fun-ptr.md index d6618aa0c36..36cf66ac327 100644 --- a/text/0000-fun-vs-fun-ptr.md +++ b/text/0000-fun-vs-fun-ptr.md @@ -6,11 +6,11 @@ # Summary It is likely that Rust will want to someday have a notion of an unboxed function type to be used -with custom pointer types.1 Ideally then today's function pointers would become `&'static`s of -functions. But this is a breaking syntactic change, and unboxed functions can probably not be exposed -by 1.0. This RFC proposals making the needed breaking syntactic change now, so unboxed functions can -be added---and function pointers turned to borrowed pointers---all backwards compatibly in the -future. +with custom pointer types.1 Ideally then today's function pointers would become +`&'static`s of functions. But this is a breaking syntactic change, and unboxed functions can +probably not be exposed by 1.0. This RFC proposals making the needed breaking changes now, so +unboxed functions can be added---and function pointers turned to borrowed pointers---all backwards +compatibly in the future. # Motivation @@ -41,37 +41,43 @@ function pointers fat, and moreover the sizes of functions are not in-general kn anyway (c.f. foreign functions). So if this requires a breaking change to make nice, yet is too big to do before 1.0, what can be -done? My suggestion is simply to simply change the syntax of function pointer types to make clear -they act like `&'statics`. This doesn't force any semantic changes in the future, but opens to door -to reusing `fn(...)...` for unboxed functions by allowing function pointers to silently become -actual `&statics` if/when function types are added in the future. Meanwhile Rust, while slightly -less ergonomic---function pointers are quite rare, is more forthright about its current -expressiveness today. +done? My suggestion is simply to make just the breaking changes now, and leave the rest for later: +change the syntax of function pointer types to make clear they act like `&'statics`, and make it so +that only "borrowed functions" coerce to function pointers. This doesn't force any semantic changes +in the future, but opens to door to reusing `fn(...)...` for unboxed functions by allowing function +pointers to silently become actual `&statics` if/when function types are added in the +future. Meanwhile Rust, while slightly less ergonomic---function pointers are quite rare, is more +forthright about its current expressiveness today. # Detailed design -Quite simply, change the syntax of function pointer types from +1. Change the syntax of function pointer types from -```rust -('extern' STRING_LIT?)? 'fn' '(' (IDEN ':' TYPE (',' IDEN ':' TYPE)* ','?)? ')' ('->' TYPE)? -``` + ```rust + ('extern' STRING_LIT?)? 'fn' '(' (IDEN ':' TYPE (',' IDEN ':' TYPE)* ','?)? ')' ('->' TYPE)? + ``` -to + to -```rust -'&' '\'static' ('extern' STRING_LIT?)? 'fn' '(' (IDEN ':' TYPE (',' IDEN ':' TYPE)* ','?)? ')' ('->' TYPE)? -``` + ```rust + '&' '\'static' ('extern' STRING_LIT?)? 'fn' '(' (IDEN ':' TYPE (',' IDEN ':' TYPE)* ','?)? ')' ('->' TYPE)? + ``` -Like slices before DST, the `fn(...) ...` itself will not denote a type on its own and need not even -parse. + Like slices before DST, the `fn(...) ...` itself will not denote a type on its own and need not + even parse. -In the future, `fn(...) ...` can be made legal syntax and given semantics, in which case the current -syntax would no longer be its own grammatical production but remain valid, and actually denote the -type of a static, immutable borrowed pointer to a function. + In the future, `fn(...) ...` can be made legal syntax and given semantics, in which case the + current syntax would no longer be its own grammatical production but remain valid, and actually + denote the type of a static, immutable borrowed pointer to a function. -Just as today, function items may have unique function types, but those types won't have a surface -syntax, and expressions (in practice just identifiers/paths) of those types will coerce to function -pointers (see [1]). + +2. Change the coercion rules so that values of the secret function types to not coerce to function + pointers, but values of immutably borrowed secret function types do instead. + + Just as today, these secret function types won't have a surface syntax. This change however + brings the coercion rules for functions in line with that for DSTs, and will prevent what would + be a much more auto-referencing if the types of functions were exposed in the + future. [Thanks @P1start for this idea.] # Drawbacks From ebcc57d77f822a0372ae8685b1277c3323ce6ad2 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Thu, 26 Feb 2015 18:47:49 -0500 Subject: [PATCH 12/12] Add examples as @huonw requested --- text/0000-fun-vs-fun-ptr.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/text/0000-fun-vs-fun-ptr.md b/text/0000-fun-vs-fun-ptr.md index 36cf66ac327..c166a1f43c1 100644 --- a/text/0000-fun-vs-fun-ptr.md +++ b/text/0000-fun-vs-fun-ptr.md @@ -78,6 +78,23 @@ forthright about its current expressiveness today. brings the coercion rules for functions in line with that for DSTs, and will prevent what would be a much more auto-referencing if the types of functions were exposed in the future. [Thanks @P1start for this idea.] + +## Examples + +```rust +fn f() { } +// f : an undenotable, (ideally) zero sized, type. Think of it as a function "proxy". +// &'static fn() is a function pointer type. +// fn() could *someday* be an unsized function type. +fn main() { + let g = f; // DEPENDS; should the proxy impls Copy? + let g = &f; // OK; g : &(an undenotable, (ideally) zero sized, type) + let g: &'static fn() = f; // ERROR: no auto-borrowing in Rust + let g: &'static fn() = &f; // OK; pointers to concrete function proxy coerce to pointers function + let g: &Fn() = &f; // OK; &magic -coerce-> &'static fn() -coerce-> &Fn trait object. Would necessitate dyanmic dispatch though. + let g: &Fn() = f; // DEPENDS; Should proxies themselves Fn? +} +``` # Drawbacks @@ -106,5 +123,8 @@ forthright about its current expressiveness today. Perhaps I am mistaken and the semantics of `&'static`s and functions pointers differ. +Should the hidden function types impl `Fn` and `Copy`? I think this depends on whether we like to bind +function IDs to an proxy type in the future, or get rid of such proxy types. + [1]: https://github.com/rust-lang/rust/pull/19891 The implementation currently distinguishes between function types and function pointer types, but this is not really exposed as part of the language.