google
Simplify type cast and remove error handling in protobuf exercise
While using .try_into().expect() is the more robust solution, I think it's more complex than we want here. We don't really care about error handling in this exercise, so I think a simple as cast is clearer here. I think we should also remove the logic for checking if there are enough bytes left, since it simplifies things and makes the solution easier to read.
Hm yeah I've noticed that sometimes things I remove for simplicity end up back in the slides. That's kind of frustrating but I get why it's happening.
Maybe that's as simple as "// TODO: Handle invalid lengths"?
I think if we put a TODO in there we're just going to get PRs trying to fix the TODO 😅. Maybe it would make sense to add something to the contribution docs stating that we want to air on the side of simplicity and clarity in the code examples and exercises, even when that makes the code less idiomatic. I don't that that'd stop the PRs, but it'd give us something to point to when somebody tries to make the code more "idiomatic" in a way that distracts from the point of the example/exercise.
That's a good idea, too, but depends on a PR author or reviewer recognizing that this is one of those err-on-the-side-of-simplicity cases. It's a shame we can't easily have comments in the source that aren't rendered in the book.
I think it's more complex than we want here. We don't really care about error handling in this exercise
Would it work to change parse_varint to return usize instead of u64?
I think that would just move the as. into parse_varint, and a varint is defined to contain a 64-bit integer, so that would be a bit odd. I've added a comment that doesn't say "TODO", maybe that will work?
@djmitche I like your comment, I think calling out that we're doing the simplest thing and not the most robust thing is a reasonable approach. Do you think this is good to merge now?