Add a mention to the associated RFC

danielhenrymantilla · Jan 30, 2022 · d472c8e · d472c8e
1 parent 034db57
commit d472c8e
Show file tree

Hide file tree

Showing 3 changed files with 9 additions and 4 deletions.
diff --git a/Cargo.lock b/Cargo.lock
diff --git a/Cargo.toml b/Cargo.toml
@@ -4,7 +4,7 @@ name = "higher-order-closure"
 authors = [
     "Daniel Henry-Mantilla <daniel.henry.mantilla@gmail.com>"
 ]
-version = "0.0.3"  # Keep in sync
+version = "0.0.4"  # Keep in sync
 edition = "2018"
 
 license = "Zlib OR MIT OR Apache-2.0"

diff --git a/README.md b/README.md
@@ -21,6 +21,11 @@ https://github.com/danielhenrymantilla/higher-order-closure.rs/actions)
 
 ### Motivation / Rationale
 
+See the [RFC #3216](https://github.com/rust-lang/rfcs/pull/3216): this crate
+is a Proof-of-Concept of the ideas laid out there[^1].
+
+[ˆ1]: with the exception of allowing elided lifetimes to have a meaning (chosen higher-order), which the RFC cannot do in order to be future-proof.
+
 <details><summary>Click to expand</summary>
 
 The following example fails to compile:
@@ -245,7 +250,7 @@ fn main ()
 
 #### Outer generic parameters
 
-Given how the macro internally works[^1], generic parameters "in scope" won't,
+Given how the macro internally works[^2], generic parameters "in scope" won't,
 by default, be available in the closure signature (similar to `const`s and
 nested function or type definitions).
 
@@ -341,7 +346,7 @@ fn main ()
 }
 ```
 
-[^1]: it generates a "closure identity" helper function, with the desired
+[^2]: it generates a "closure identity" helper function, with the desired
 higher-order signatures embedded as `Fn` bounds on its parameters, thus making
 it act as a "funnel" that only lets closure with the right signature pass
 through).