{"id":5822,"date":"2021-04-02T07:00:30","date_gmt":"2021-04-02T14:00:30","guid":{"rendered":"http:\/\/writeasync.net\/?p=5822"},"modified":"2021-03-31T10:34:48","modified_gmt":"2021-03-31T17:34:48","slug":"letter-boxed-rust-impl-part-2-panicking-hashing-parsing","status":"publish","type":"post","link":"https:\/\/writeasync.net\/?p=5822","title":{"rendered":"Letter Boxed: Rust impl, part 2 (panicking, hashing, parsing)"},"content":{"rendered":"

Previously we began our Rust exploration of Letter Boxed<\/a> with the core St<\/code> and Ch<\/code> structs. Now we’ll complete their functionality.<\/p>\n

The next test on our TODO list looks like this in the C# version<\/a>:<\/p>\n

\r\n        [Fact]\r\n        public void AppendTooMany()\r\n        {\r\n            Str max = default(Str)\r\n                .Append(Ch.A)\r\n                .Append(Ch.B)\r\n                .Append(Ch.C)\r\n                .Append(Ch.D)\r\n                .Append(Ch.E)\r\n                .Append(Ch.F)\r\n                .Append(Ch.G)\r\n                .Append(Ch.H)\r\n                .Append(Ch.I)\r\n                .Append(Ch.J)\r\n                .Append(Ch.K)\r\n                .Append(Ch.L);\r\n\r\n            Action act = () => max.Append(Ch.X);\r\n\r\n            act.Should().Throw<InvalidOperationException>();\r\n        }\r\n<\/pre>\n
We’ve already encountered our first roadblock — Rust does not have exceptions<\/a>. Instead, you either use an error result<\/a> for things that could reasonably happen in a typical flow (e.g. when parsing external data) or you panic<\/a>! We’ll choose the latter in this particular case; appending past the end of a buffer is an indication of an incorrect program and not something that we would want to compensate for or recover from.<\/p>\n
Here is the Rust version of this test, using the [should_panic]<\/a> annotation:<\/p>\n
\r\n    #[test]\r\n    #[should_panic(expected = "Cannot append any more")]\r\n    fn append_too_many() {\r\n        let max = St::empty()\r\n            + Ch::A\r\n            + Ch::B\r\n            + Ch::C\r\n            + Ch::D\r\n            + Ch::E\r\n            + Ch::F\r\n            + Ch::G\r\n            + Ch::H\r\n            + Ch::I\r\n            + Ch::J\r\n            + Ch::K\r\n            + Ch::L;\r\n\r\n        let _ = max + Ch::X;\r\n    }\r\n<\/pre>\n
Note the use of the underscore variable<\/a> since we expect this line to panic and cannot do anything with the value. To pass this test, we only need a small tweak to the add<\/code> function:<\/p>\n
\r\n    fn add(self, rhs: Ch) -> Self::Output {\r\n        if self.len() == 12 {\r\n            panic!("Cannot append any more");\r\n        }\r\n        \/\/ . . .\r\n    }\r\n<\/pre>\n
Not bad! We can follow this same pattern for the index out of range condition<\/a> and the new chop<\/code> function<\/a> which drops the last Ch<\/code> from the St<\/code>.<\/p>\n
The end goal with St<\/code> is to support a fast lookup strategy, so naturally we should reach for the Hash trait<\/a> next. It is auto-derivable<\/a>, with the default implementation hashing all fields together. How convenient. There is  an important difference in how hashing works in Rust compared to .NET, however. Since Rust has no implementation inheritance<\/a> and no universal base class<\/a>, we can’t just make a virtual GetHashCode method<\/a> and be done with it. Instead, “hashable” types are supposed to produce their hash code when given a “hasher”<\/a> which allows a bit more modularity between the what (i.e. data to consider) and the how (i.e. the algorithm) of hashing. You can see this difference by comparing the C# and Rust versions of the hash code test:<\/p>\n
\r\n        [Fact]\r\n        public void HashCode()\r\n        {\r\n            Str empty = default(Str);\r\n            Str a = default(Str).Append(Ch.A);\r\n            Str b = default(Str).Append(Ch.B);\r\n            Str ab = default(Str).Append(Ch.A).Append(Ch.B);\r\n            Str ba = default(Str).Append(Ch.B).Append(Ch.A);\r\n            Str cdefgh = default(Str).Append(Ch.C).Append(Ch.D).Append(Ch.E).Append(Ch.F).Append(Ch.G).Append(Ch.H);\r\n\r\n            HashSet<int> codes = new HashSet<int>(new Str[] { empty, a, b, ab, ba, cdefgh }.Select(s => s.GetHashCode()));\r\n\r\n            codes.Should().HaveCount(6);\r\n        }\r\n<\/pre>\n
In Rust, we have the extra step of working with a mutable<\/a> hasher:<\/p>\n
\r\n    #[test]\r\n    fn hash_code() {\r\n        let empty = St::empty();\r\n        let a = St::empty() + Ch::A;\r\n        let b = St::empty() + Ch::B;\r\n        let ab = St::empty() + Ch::A + Ch::B;\r\n        let ba = St::empty() + Ch::B + Ch::A;\r\n        let cdefgh = St::empty() + Ch::C + Ch::D + Ch::E + Ch::F + Ch::G + Ch::H;\r\n        let values = vec![empty, a, b, ab, ba, cdefgh];\r\n\r\n        let codes: HashSet<u64> = values\r\n            .into_iter()\r\n            .map(|s| {\r\n                let mut hasher = DefaultHasher::new();\r\n                s.hash(&mut hasher);\r\n                hasher.finish()\r\n            })\r\n            .collect();\r\n        assert_eq!(6, codes.len());\r\n    }\r\n<\/pre>\n
It’s a slight difference but not all that impactful outside the unit testing context. In a typical program, we are unlikely to directly ask for the hash code (we’d probably just put the item in a HashMap<\/a> and let the collection do the heavy lifting).<\/p>\n
The last requirement is the ability to convert a string like “HELLO” into a St<\/code> with values Ch::H<\/code>, Ch::E<\/code>, Ch::L<\/code>, Ch::L<\/code>, Ch::O<\/code> inside. As you may have guessed, there’s a trait for that — FromStr<\/a>. Unlike some other traits, the from_str<\/code> method here is not typically used directly. Rather, you call str::parse<\/code><\/a> which in turn calls from_str<\/code>. As the docs say, you will more than likely have to use the “turbofish syntax”<\/a> to ensure Rust understands what the output type should be in context. Here is the unit test showing this in action:<\/p>\n
\r\n    #[test]\r\n    fn parse_from_string() {\r\n        test_parse("");\r\n        test_parse("A");\r\n        test_parse("BC");\r\n        \/\/ . . .\r\n    }\r\n\r\n    fn test_parse(expected: &str) {\r\n        let s = expected.parse::<St>().unwrap();\r\n        assert_eq!(expected, s.to_string());\r\n    }\r\n<\/pre>\n
As a final note, you should be aware that Rust considers string parsing to be a fallible conversion<\/a>. As such, the return value is a Result type<\/a> that can have either a value or an error. In this case, we don’t want to bother with returning an error and will just assume that converting to St<\/code> will either succeed or panic. While we cannot change the function signature, we can indicate there is no such thing as an error here by using the unit type<\/a> (essentially “void”<\/a>):<\/p>\n
\r\nimpl FromStr for St {\r\n    type Err = ();\r\n\r\n    fn from_str(s: &str) -> Result<St, ()> {\r\n        let mut value = St::empty();\r\n        for c in s.chars() {\r\n            let c = match c {\r\n                'A' => Ch::A,\r\n                \/\/ . . .\r\n                'Z' => Ch::Z,\r\n                _ => Ch::None,\r\n            };\r\n            value = value + c;\r\n        }\r\n\r\n        Ok(value)\r\n    }\r\n}\r\n<\/pre>\n
The type Err = ();<\/code> line says that our error type is nothing at all, and as a consequence, our function returns Ok<\/code> in all (non-panic) paths.<\/p>\n
With that, our base data structure logic is done: [see code on GitHub]<\/a><\/p>\n
Going forward, we’ll get into the nuts and bolts of the higher level algorithms and structures of Letter Boxed. See you again soon!<\/p>\n","protected":false},"excerpt":{"rendered":"
Previously we began our Rust exploration of Letter Boxed with the core St and Ch structs. Now we’ll complete their functionality. The next test on our TODO list looks like this in the C# version: [Fact] public void AppendTooMany() {… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[91,101,41],"tags":[],"class_list":["post-5822","post","type-post","status-publish","format-standard","hentry","category-design","category-native","category-tdd"],"_links":{"self":[{"href":"https:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/posts\/5822","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/writeasync.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5822"}],"version-history":[{"count":5,"href":"https:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/posts\/5822\/revisions"}],"predecessor-version":[{"id":5827,"href":"https:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/posts\/5822\/revisions\/5827"}],"wp:attachment":[{"href":"https:\/\/writeasync.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5822"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/writeasync.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5822"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/writeasync.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5822"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}