We may need documentation updated for function pointers when used in enums. I won't pretend I understand half of what's written here, but here's the log from IRC (#rust_beginners) where we debugged this issue: 1. [Rust Playground (`Sharlin`)](https://play.rust-lang.org/?gist=d25cb785bee399efe590293ab2c1a44a&version=stable) 2. [Rust Playground (`spear2`)](https://play.rust-lang.org/?gist=0cfe1a8e458fa50d5223054f7ff7298c&version=stable]) ``` Sharlin :: vermiculus: okay... wtf [1] vermiculus :: Sharlin: Right!? Sharlin :: what makes fns with ref arguments not implement Ord or anything vermiculus :: I 100% need the argument to be mutable, but I can't have it be mutable without being a ref, and apparently it's choking on the ref spear2 :: maybe it has to do with the reference having an implicit lifetime? vermiculus :: ...Ok the '100%' is not completely true, but it's the cleanest option Sharlin :: spear2: indeed it seems to be spear2 :: [2] vermiculus :: spear2: now there's a topic I still don't understand half or less Sharlin :: this is definitely something that should be documented in the fn docs :D vermiculus feels useful :D spear2 :: vermiculus: the way i understand it, every reference has an associated lifetime, but most of the time it can be 'inferred' and you don't see it Sharlin :: so this is about that higher ranked trait bound thingie vermiculus :: spear2: that's the extent of my understanding as well; I get tripped up trying to 'infer' the lifetime myself (effectively seeing what the compiler would see) Sharlin :: `Bar(fn(&i32))` is actually `Bar(for<'a> fn(&'a i32))` Sharlin :: which means the fn is not an ordinary function pointer but a higher something vermiculus :: spooky vermiculus :: that makes me wonder if this behavior is intentional or if there's a more explicit means to express this idea vermiculus :: throwing that explicit lifetime parameter is making the rest of the compiler go a little nutty -- wanting lifetime parameters for *everything* :( Sharlin :: yeah Sharlin :: so it goes ```