Implemented HashMap::try_insert

[GarkGarcia]

Follow up on #58.

---

This change is 

[domenicquirl]

Thanks, this looks good! Especially the effort you put into the documentation 😊

I've left some comments, mainly I think we should do the change to a Result return value. This None on success thing still confuses me 😅

[jonhoo]

Ah, I saw just now that the existing insert method has docs similar to the ones I just had you rewrite :p Maybe we should update the insert docs to match the style of the new try_insert docs while we're at it?

[GarkGarcia]

Ah, I saw just now that the existing insert method has docs similar to the ones I just had you rewrite :p Maybe we should update the insert docs to match the style of the new try_insert docs while we're at it?

Exactly! Gonna work on this.

[jonhoo]

#76 has now landed!

[GarkGarcia]

All done I think.

[jonhoo]

I still think we should use the TryInsertError struct I proposed earlier, since currently the user has no way to recover the value (or key) they provided in the case of a failed insert.

[jonhoo]

See #77 for a way to recover the value.

[GarkGarcia]

I still think we should use the TryInsertError struct I proposed earlier, since currently the user has no way to recover the value (or key) they provided in the case of a failed insert.

I'm not quite sold on this proposal. Although it does provide some useful functionality which is not provided in our current public API, I seems a bit cumbersome and unergonomic.

Also, since this is a public API, we'd probably have to implement the ? operator for it, besides some traits for useful conversions.

[domenicquirl]

Can/did you run cargo fmt --all -- --check exactly? That's what the CI task checks against.

Regarding the fields, I don't actually know; can you destructure a struct if it's fields are private? I would like the user to be able to do

match map.try_insert(&i, value, &guard) {
	Ok(new) => {...},
	Err(TryInsertError { old, not_inserted } ) => {...}
}

[GarkGarcia]

Regarding the fields, I don't actually know; can you destructure a struct if it's fields are private? I would like the user to be able to do

match map.try_insert(&i, value, &guard) {
	Ok(new) => {...},
	Err(TryInsertError { old, not_inserted } ) => {...}
}

Nope, you can't. I think you can deconstruct them inside the matches! macro, but I'm not sure and that's pretty limited anyway.

[GarkGarcia]

Can/did you run cargo fmt --all -- --check exactly? That's what the CI task checks against.

Just did it:

$ cargo fmt --all -- --check
Diff in ~/Documents/flurry/src/map.rs at line 135:

 #[derive(Eq, PartialEq, Clone, Debug)]
 enum PutResult<'a, T> {
-    Inserted {
-        new: &'a T,
-    },
-    Replaced {
-        old: &'a T,
-        new: &'a T,
-    },
-    Exists {
-        old: &'a T,
-        not_inserted: Box<T>,
-    },
+    Inserted { new: &'a T },
+    Replaced { old: &'a T, new: &'a T },
+    Exists { old: &'a T, not_inserted: Box<T> },
 }

 impl<'a, T> PutResult<'a, T> {

Dunno why cargo fmt hasn't fixed it by itself. Anyway, on my way to fixing it.

[domenicquirl]

Nope, you can't. I think you can deconstruct them inside the matches! macro, but I'm not sure and that's pretty limited anyway.

Then I'm against making them private. I think it's not worth for them to be private if we lose the destructuring

[GarkGarcia]

Nope, you can't. I think you can deconstruct them inside the matches! macro, but I'm not sure and that's pretty limited anyway.

Then I'm against making them private. I think it's not worth for them to be private if we lose the destructuring

Makes sense. @jonhoo what do you think?

[jonhoo]

I am strongly in favor of both fields being public. We could mark it #[non_exhaustive], but I don't think even that's necessary.

[GarkGarcia]

I am strongly in favor of both fields being public. We could mark it #[non_exhaustive], but I don't think even that's necessary.

Alright, public it is. Marking things as #[non_exhaustive] is good practice.

I guess the only things left to do are:

• Polishing the documentation of TryInsertError and TryInsertResult.
• Implementing Display and Error for TryInsertError.

[jonhoo]

The biggest downside of #[non_exhaustive] is that people now must match on TryInsertError with , .., which is a bit of an ergonomic penalty. I guess the question is how likely we think it is that we'll want to change it later. I think it's fairly unlikely..?

[GarkGarcia]

The biggest downside of #[non_exhaustive] is that people now must match on TryInsertError with , .., which is a bit of an ergonomic penalty. I guess the question is how likely we think it is that we'll want to change it later. I think it's fairly unlikely..?

Fair enough. Seems unlikely indeed.

Resolved

[GarkGarcia]

Thanks @jonhoo and @domenicquirl for the help! 😁️

[jonhoo]

Thanks for taking the time to implement it, and to follow up on all our nitpicking 😅