Extended timestamp returns Option<&u32>
, which could be copied instead (so Option<u32>
)
#183
Labels
enhancement
New feature or request
fix merged
Fix is merged, but the issue will stay open until it's released.
Is your feature request related to a problem? Please describe.
So I'm getting the modification times of a file inside a zip file, with the methods here:
zip2/src/extra_fields/extended_timestamp.rs
Lines 73 to 86 in 28fb992
It's annoying to have to deal with
Option<&u32>
. In some cases you need to deref it (so something likeif let Some(x) = file.ac_time() { let time = *x; ... }
), or you need to use.copied()
to convertOption<&u32>
intoOption<u32>
.Describe the solution you'd like
I think it would be better to have this api return
Option<u32>
, sinceu32
is easily copyable.One way would be to have methods like
Describe alternatives you've considered
The alternative to this is to put use
x.cr_time().copied()
, instead of the proposedx.creation_time()
.Another idea would be to have these return some struct encapsulating the fact that it's actually an unix timestamp that's stored here. This struct would look like
UnixTimestamp(u32)
, and would also#[derive(Copy)]
.Another idea would be to have a proper time type, from some other crate (
chrono
?).The text was updated successfully, but these errors were encountered: