-
Notifications
You must be signed in to change notification settings - Fork 508
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement generic assign operations for various types #925
Conversation
Includes: * `oldtime::Duration` * `datetime::DateTime` * `naive::date::NaiveDate` * `naive::datetime::NaiveDateTime` * `naive::time::NaiveTime` Did not implement it for `date::Date`. This is because `Add` expects to be passed the owned object, but `AddAssign` only has access to a mutable reference. Since `Date` doesn't implement `Copy`, that makes it impossible to generically and safely implement `AddAssign` using `Add` without cloning. It might be possible with unsafe code, but that's probably over the top. `date::Date` is deprecated anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry to add some late comments to this PR.
These implementations make chrono a little nicer to use. Methods such as check_add_*
have their use, but these AddAssign
implementations are just convenient. So 👍 from me.
But: a generic implementation will not only affect chrono, but also library users.
If a user has impl Add<MyType> for NaiveDate
and impl AddAssign<MyType> for NaiveDate
, that would no longer compile because of the new generic implementation of AddAssign
here, right?
This would be a (minor) breaking change for 0.4.x.
I don't think a blanked implementation is a good thing to have in general. Or said differently: if it is just a way to save some code in chrono, it is better to write the individual implementations.
@@ -982,6 +962,30 @@ impl<Tz: TimeZone> Sub<Days> for DateTime<Tz> { | |||
} | |||
} | |||
|
|||
impl<T, Tz: TimeZone> AddAssign<T> for DateTime<Tz> | |||
where | |||
NaiveDateTime: Add<T, Output = NaiveDateTime>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not correct. The Add
implementation of Days
and Months
with DateTime
is timezone-aware. I think the correct way to do this is to just add the individual implementations.
|
||
impl<T, Tz: TimeZone> SubAssign<T> for DateTime<Tz> | ||
where | ||
NaiveDateTime: Sub<T, Output = NaiveDateTime>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same for Sub
@@ -381,6 +381,42 @@ impl Div<i32> for Duration { | |||
} | |||
} | |||
|
|||
impl<T> AddAssign<T> for Duration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably best to stay clear of `Duration for now, see #1054.
@yottalogical would you be willing to add the individual assign operations? And @djc would you agree they can be useful? |
Closing due to inactivity. The related issue to track is #70. |
Includes:
oldtime::Duration
datetime::DateTime
naive::date::NaiveDate
naive::datetime::NaiveDateTime
naive::time::NaiveTime
Did not implement it for
date::Date
. This is becauseAdd
expects to be passed the owned object, butAddAssign
only has access to a mutable reference. SinceDate
doesn't implementCopy
, that makes it impossible to generically and safely implementAddAssign
usingAdd
without cloning. It might be possible with unsafe code, but that's probably over the top.date::Date
is deprecated anyways.