Naked Unwraps

[njgheorghita]

I don't have a reproducible issue that I can show, but I can conclusively say that as I go about debugging this library I do run into panicked threads due to naked unwraps. In trin we took a firm stance against the use of naked unwraps. (According to clippy) there are 31 naked unwraps in utp. Some of which have documentation explaining their use. Some of which don't contain documentation. There are cases where naked unwraps are used in methods that do not return a Result which complicates resolving these unwraps.

I guess I'm just curious about the decision to allow naked unwraps in this library. Why? What was the criteria for using an unwrap vs implementing error handling for individual cases? It seems to me like resolving these unwraps would improve the performance of this library, but would like to get some confirmation before undertaking the task.

[njgheorghita]

I guess a simpler option to eliminate all the naked unwraps could be to just convert them to expect()s

[jacobkaufmann]

yea.. some of the unwrap instances were for expediency, and in other cases they represent assertions that should not fail. in such cases where you expect invariants to hold, I think unwrap is acceptable. I can take a look. if there are common places where the code panics, then that would be helpful.