Updated Proposal for closure reform (specific) (markdown)

Proposal-for-closure-reform-(specific).md

@@ -24,7 +24,7 @@ So, the grammar for function types is simply: ```{[&]|~|@}[once ]fn[:k1[+k2...]]
 * No function type may be promoted to an ```&T``` if we do dynamically-sized types. We could make this more obvious by putting the sigil after the keyword like we had before (```fn&```, ```fn~```). This would also make it more clear that once fns are consumed when called (```once fn&()```). Another possibility is the notation ```once &fn()```.
 * If we want to make functions derive ```Clone```, we'll have to autogenerate a function for cloning the environment, and include a pointer to it in the environment packet (so it could optionally be promoted to a function without ```Clone```), like a vtable. This could optionally be extended (with more difficulty) to support deriving other traits, like ```Eq```. This entire feature is optional; we could also say closures can only derive built-in bounds, and avoid generating vtable-like code.
 * A stack closure that wants to mutate its upvars has to dereference the borrowed pointer to them, such as ```let mut x = None; do something |val| { *x = Some(val); }```. When making method calls, autoderef will make this look the same as before; otherwise, a user who tries to do "the familiar thing" (i.e., write ```x = Some(val)```) will get an easy-to-understand type error. This proposal could instead be done with the "implicit reference" scheme of today, but then stack closures will only be copyable if they also satisfy ```Const```.
-* If we keep ```@fn()```, it will have to have a dynamic recursion barrier (analogous to ```@mut T```), unless it can satisfy ```@fn:Const()``` (analogous to ```@T```).
+* If we keep ```@fn()```, it will have to have a dynamic recursion barrier (analogous to ```@mut T```), unless it can satisfy ```@fn:Const()``` or ```@fn:Owned()``` (analogous to ```@T```).
 
 **Advantages**