Skip to content

Add with_* methods to Date and DateTime #84

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

Merged
merged 3 commits into from
Jul 17, 2024
Merged

Add with_* methods to Date and DateTime #84

merged 3 commits into from
Jul 17, 2024

Conversation

nekevss
Copy link
Member

@nekevss nekevss commented Jul 17, 2024

Per title, this PR adds with_calendar and with_time methods to Date and DateTime. This also adds some From impls for Calendar.

@nekevss nekevss added C-enhancement New feature or request C-api Changes related to the public API labels Jul 17, 2024
calendar: dt.calendar().clone(),
}
/// Creates a
pub fn with_calendar<I>(&self, calendar_like: Option<I>) -> TemporalResult<Self>
Copy link
Member

@jedel1043 jedel1043 Jul 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should accept an Option<I: Into<Calendar>> for something that only requires a calendar. We should just require users to pass the calendar directly, and delegate calling into to them.

Copy link
Member Author

@nekevss nekevss Jul 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair. The intent in this instance was to try and mimic the proposal as much as possible around accepting a calendarLike vs. a calendar. But there's not really any negative to restricting to just a calendar. It's probably a better API too.

Mostly speaking of #55 as far as the API, but maybe that should be rethought?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the spec API is fine, but in my opinion the APIs should be adapted to the explicitness of Rust APIs instead of having a 1-1 equivalent in both, which in this case means having some function that people can call to get the calendar before calling the function, instead of filling the API with generics.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is partly because any APIs that have generics in them will make it really difficult to implement FFI interfaces for them.

Copy link
Member

@jedel1043 jedel1043 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

@nekevss nekevss merged commit 6a621b7 into main Jul 17, 2024
5 checks passed
@nekevss nekevss deleted the impl-with-methods branch July 19, 2024 02:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-api Changes related to the public API C-enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants