Skip to content
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

Closed

Conversation

yottalogical
Copy link

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.

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.
@yottalogical yottalogical marked this pull request as ready for review January 7, 2023 22:42
Copy link
Collaborator

@pitdicker pitdicker left a 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>,
Copy link
Collaborator

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>,
Copy link
Collaborator

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
Copy link
Collaborator

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.

@pitdicker
Copy link
Collaborator

@yottalogical would you be willing to add the individual assign operations? And @djc would you agree they can be useful?

@pitdicker
Copy link
Collaborator

Closing due to inactivity. The related issue to track is #70.

@pitdicker pitdicker closed this Jul 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants