The current `Result` type hardcodes the error as a `str`:
```
enum Result { Ok(T), Err(str) }
```
This means you can't carry structured errors, can't pattern-match on error kinds, and can't chain results that have different error types. It's fine for quick scripts but breaks down as soon as you want real error handling.
The fix is to add a second type parameter:
```
enum Result<T, E> { Ok(T), Err(E) }
```
This is a breaking change to the existing API, but better to do it before the ecosystem grows. Code using `Result` today would become `Result<T, str>` in a migration.
The current `Result` type hardcodes the error as a `str`:
```
enum Result { Ok(T), Err(str) }
```
This means you can't carry structured errors, can't pattern-match on error kinds, and can't chain results that have different error types. It's fine for quick scripts but breaks down as soon as you want real error handling.
The fix is to add a second type parameter:
```
enum Result<T, E> { Ok(T), Err(E) }
```
This is a breaking change to the existing API, but better to do it before the ecosystem grows. Code using `Result` today would become `Result<T, str>` in a migration.