Skip to content

Add >= and <= to Date - #2223

Open
stephentyrone wants to merge 2 commits into
swiftlang:mainfrom
stephentyrone:fix-date-comparable
Open

Add >= and <= to Date#2223
stephentyrone wants to merge 2 commits into
swiftlang:mainfrom
stephentyrone:fix-date-comparable

Conversation

@stephentyrone

Copy link
Copy Markdown
Contributor

Without these, Date falls back on the default implementations from Comparable, which do not handle NaN correctly.

Before this change, both Date(timeIntervalSince1970: .nan) <= Date(timeIntervalSince1970: 0) and Date(timeIntervalSince1970: .nan) >= Date(timeIntervalSince1970: 0) would be true. Now they are false.

Without these, we fall back on the default implementations from Comparable, which do not handle NaN correctly.
@stephentyrone
stephentyrone requested a review from a team as a code owner September 3, 2026 15:55
}

/// Returns true if the left hand `Date` is earlier in time than or equal to the right hand `Date`.
public static func <=(lhs: Date, rhs: Date) -> Bool {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think these will need to be @export(implementation) or @backDeployed since they can't have stricter availability than the protocol conformance, is that correct?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

IIRC the symbols are already there because the protocol requires them and provides defaults, so we shouldn't need availability, but we can export them and get the fix to more targets.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Oh right sorry, I confused declarations that the compiler synthesizes (and creates the ABI symbol for) with default implementations inherited from extensions on the protocol (which don't create a symbol since it uses the symbol from the default implementation instead) - my bad.

I think @export(implementation) would actually now remove that symbol right? So maybe just leaving it as it was without availability is the way to go 😅

This way we can get the right behavior on older systems too (after a recompile).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants