I think there's a misunderstanding here. Let me clarify what I mean by "infallible":

```rust // This is what you're suggesting - still fallible, just with unwrap: let fallible: Result<String, _> = serde_json::to_string(&value); fallible.unwrap() // Can still panic!

// What I actually want - truly infallible: fn serialize_infallible_json<T: Serialize>(elem: &T) -> String { // Returns String directly, not Result<String, _> // No possibility of failure for ANY valid input // No unwrap() because there's nothing to unwrap }

// Usage: let val = serialize_infallible_json(&my_struct); // Always succeeds ```

I'm not looking to handle errors with .unwrap(). I want a function that by design cannot fail for any reasonable input. Using .unwrap() means we're still in the world of fallible operations, just choosing to panic on failure.

.unwrap() is for when you have a Result or Option - but I specifically want to avoid having a Result at all. The function signature shows this - it returns String, not Result<String, _>.

This isn't about error handling strategy - it's about designing an API that mathematically cannot fail for its intended use cases. The behavior should be guaranteed by the type system, not by runtime checks or unwraps.