3 ms·
> you'd have a lifetime annotation on your Error guaranteeing that your Error does not outlive your allocated path This has implications that are obviously und
by voidnap 3y ago
> you'd have a lifetime annotation on your Error guaranteeing that your Error does not outlive your allocated path
This has implications that are obviously undesirable, like prohibiting returning errors borrowing file paths allocated on the stack.
- littlestymaar 3y agoNo, if you need your error to outlive the path, then you can create a dedicated error that hold the path itself. This way it could lead to an allocation, but only when you actually need it. In your particular example you could memcopy the path in the Error, without allocating at all (but you may also want to box the path instead if the path made the enum size too big).
- voidnap 3y ago> can create a dedicated error that hold the path itself. Right making the standard library's error type far less useful if you have to start writing your own error types lol. That's such an obnoxious design. The way it is now you can write programs that return and handle io errors just fine when they don't care about the path or other arguments. Your suggestion would require those programs to make a dedicated error type to unabstract away what is essentially a thin wrapper around errno. The value of a `std::io::Error` is still obviously appealing.