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

[SR-8728] Add note about conditional conformance to RandomAccessCollection docs #51238

natecook1000 opened this issue Sep 11, 2018 · 2 comments
improvement standard library Area: Standard library umbrella


Copy link

Previous ID SR-8728
Radar None
Original Reporter @natecook1000
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Improvement, StarterDocs
Assignee None
Priority Medium

md5: da79f458aac27d0c55f972597f643c77

Issue Description:

Because RandomAccessCollection has only semantic requirements that refine , it's easy for conditionally conforming types to implement the requirements in such a way that they don't receive dynamic dispatch, as seen in this forum post. We should add a note about implementing distance(from:to:) and index(_:offsetBy:) in the unconditional part of the type's declaration, if possible.

Copy link

I'm not sure why this is specific to RandomAccessCollection. Not using constrained implementations happens for any hierarchy of refining protocols.

Copy link

Comment by Dennis Vennink (JIRA)

Just a heads up.

The article on the blog that introduced conditional conformances contains an example type (LazySplitCollection) which is not a complete implementation of BidirectionalCollection.

Because of an additional conditional conformance it will trap in certain cases when traversed backwards, e.g. formIndex(_:offsetBy🙂 with a distance of -1, since BidirectionalCollection's default implementations can't be reached from Collection's default implementations. (/cc @airspeedswift.)

So indeed, this is not specific to RandomAccessCollection and we should consider extending the documentation to cover other (Collection) types as well. This could be done with a note or a label per member.

It might also be worth considering to extend this to the compiler as a warning or error as this behaviour is hard to catch without integration tests or benchmarks.

@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
improvement standard library Area: Standard library umbrella
None yet

No branches or pull requests

3 participants