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

Jump to bottom

[SR-12113] Sequence.max(), .max(by:), .min(), .min(by:) should document ambiguity resolution #54549

Open
lilyball mannequin opened this issue Jan 30, 2020 · 3 comments
Open

[SR-12113] Sequence.max(), .max(by:), .min(), .min(by:) should document ambiguity resolution #54549

lilyball mannequin opened this issue Jan 30, 2020 · 3 comments
Assignees
@natecook1000
Labels
improvement standard library Area: Standard library umbrella

Comments

@lilyball
Copy link
Mannequin

lilyball mannequin commented Jan 30, 2020

Previous ID SR-12113
Radar rdar://problem/59132835
Original Reporter @lilyball
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Improvement
Assignee @natecook1000
Priority Medium

md5: e9f6410fc30a27624842e038e73b423c

Issue Description:

When a sequence contains multiple maximum or minimum elements, the methods max(), max(by:), min(), and min(by:) seem to prefer returning the earlier element, but this isn't documented. I'd like to feel secure in relying on this behavior, so it would be great to have this reflected in the method documentation. Or if the standard library doesn't want to guarantee this then it should explicitly call that out.
@beccadax
Copy link
Contributor

beccadax commented Feb 4, 2020

@swift-ci create

@airspeedswift
Copy link
Member

I think it's reasonable to document this for the ones that take a closure. But Equatable.== implies substitutability, so the most conservative position would be to not make that same guarantee for those because it's dubious to be relying on it mattering, so reasonable to reserve the flexibility. That's probably just me being picky though.

@lilyball
Copy link
Mannequin Author

lilyball mannequin commented Feb 8, 2020

I see that argument. I would counter that equatable doesn't mean indistinguishable, and in particular objects will always be distinguishable by object address even if they're equal in all other respects, but I won't be particularly upset if the non-closure variants don't make the guarantee.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@natecook1000 natecook1000

Labels
improvement standard library Area: Standard library umbrella
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@beccadax @airspeedswift