4 ms·

> (b) it requires allocating memory to store the copy, and some languages (like Rust) do not want silent memory allocation as a default behaviour. There's no n

> (b) it requires allocating memory to store the copy, and some languages (like Rust) do not want silent memory allocation as a default behaviour. There's no need for an allocation: you already have the path allocated somewhere since you're making the call. So you could just have a pointer to that path in the error. That would obviously be very dangerous in C, because then you'd have to be careful not to have your error outlive your allocated path, but in Rust you'd have a lifetime annotation on your Error guaranteeing that your Error does not outlive your allocated path.

duped 3y ago
> but in Rust you'd have a lifetime annotation on your Error guaranteeing that your Error does not outlive your allocated path. That's a really heavy constraint that doesn't work in practice - errors usually bubble up past the scope of the arguments of whatever failed.
- littlestymaar 3y ago
  This design would force you to make a choice: if you want to bubble the error up[1], then you either: - discard the file path - allocate This way, you control the performance/UX trade-off. And it doesn't require much work: it's just a From implementation to add to your error enum. [1] only higher than the actual owned path actually.
  - insanitybit 3y ago
    What you're talking about is very practical imo and likely the right solution, but unfortunately would be a breaking change (you can't just add a lifetime annotation to the error).
    - littlestymaar 3y ago
      It's not even my biggest complaint about std::fs, the entire module feels very much not like the rest of Rust and way too close to the underlying libc (for legitimate reasons: they couldn't release Rust 1.0 without file access and likely didn't have much bandwidth to work on an alternative API). Maybe some day Rust will support multiple versions of the stdlib (in a compatible way, like what's done with editions) but until then we'll have to work with this half-baked corner of the language.
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 ago
  No, 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.

duped 3y ago

> but in Rust you'd have a lifetime annotation on your Error guaranteeing that your Error does not outlive your allocated path. That's a really heavy constraint that doesn't work in practice - errors usually bubble up past the scope of the arguments of whatever failed.

littlestymaar 3y ago
This design would force you to make a choice: if you want to bubble the error up[1], then you either: - discard the file path - allocate This way, you control the performance/UX trade-off. And it doesn't require much work: it's just a From implementation to add to your error enum. [1] only higher than the actual owned path actually.
- insanitybit 3y ago
  What you're talking about is very practical imo and likely the right solution, but unfortunately would be a breaking change (you can't just add a lifetime annotation to the error).
  - littlestymaar 3y ago
    It's not even my biggest complaint about std::fs, the entire module feels very much not like the rest of Rust and way too close to the underlying libc (for legitimate reasons: they couldn't release Rust 1.0 without file access and likely didn't have much bandwidth to work on an alternative API). Maybe some day Rust will support multiple versions of the stdlib (in a compatible way, like what's done with editions) but until then we'll have to work with this half-baked corner of the language.

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 ago
No, 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.