Example is missing a generic about high-assurance-rust HOT 3 OPEN

Hey all! Thank you both for looking into this.

Indeed, the text mentions BTreeMap<K, V> and the focus is on why Ord alone doesn't quite get us everything we'd want. So these snippets omit the K and V for brevity.

However, I agree the suggested change would be an improvement! Having both the current text and impl<K, V> BTreeMap<K, V> { ... } code blocks is likely the most clear: Q stands out more as being introduced by fn get<Q> and missing from the impl<K, V> scope (as pointed out). And in this paragraph we're still talking about BTreeMap, haven't gotten to scapegoat trees yet!

I read this really great blog post once about writing technical books. Can't find the original link (will share if I find it later) but the advice was something like "always go for clear over clever, if it's not clear then it can't be clever". Here omitting K and V is "clever" but makes things less "clear". 😉

How about making the suggested change to the first 2 code blocks containing fn get in this section? Would you like to PR this update?

IMO the last block containing fn get, which adds Default to the signature, is safe to leave as is because by that point the reader will be aware of the surrounding impl - having seen it twice before.

from high-assurance-rust.

While I like including explicit information,

This information is already stated a line previously.

Based on the above, you might expect the get method's signature to look like this for BTreeMap<K, V>:

furthermore, it distracts from the objective of the article.
I would like to mention that this article isn't a tutorial for building a BTreeMap (otherwise, direct copy and paste would be desirable), but rather an explanation of why BTreeMap uses more than just Ord as a constraint.

from high-assurance-rust.

Hey, sorry for the super late reply. I will look into creating a PR for this today!

from high-assurance-rust.