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
[stdlib] Nest Iterator and Index types for various stdlib types #13489
Conversation
@swift-ci please smoke benchmark |
@swift-ci please test source compatibility |
@swift-ci please smoke test compiler performance |
@swift-ci please test |
Iterator
and Index
types for various stdlib types
Build comment file:Optimized (O)Regression (5)
Improvement (18)
No Changes (307)
Unoptimized (Onone)Regression (7)
Improvement (18)
No Changes (305)
Hardware Overview
|
072b055
to
e157842
Compare
@swift-ci please test |
@swift-ci please smoke test compiler performance |
Build comment file:Summary for master smoketestUnexpected test results, stats may be off for unknown Regressions found (see below) Debugdebug briefNone debug detailedNone Releaserelease briefNone release detailedNone |
@shahmishal @graydon any ideas why the compiler perf tests are failing? Error in the logs says:
|
@swift-ci please test source compatibility |
Neat! |
extension EmptyCollection { | ||
/// An iterator that never produces an element. | ||
@_fixed_layout // FIXME(sil-serialize-all) | ||
public struct Iterator { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could EmptyCollection
just be its own Iterator
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess. I think I prefer it consistent tho.
@swift-ci please smoke test compiler performance |
@airspeedswift , this caused the regression in https://bugs.swift.org/browse/SR-6654 |
Nests various custom iterators and indexes for stdlib types inside their used types. This has been possible for a while now that we have nested generics, and cleans up the namespace.
Should be a non-functional-change for now with type aliases for the old names which aren't yet deprecated (deprecation/removal of type aliases is not ABI impacting so can be done at any time).
Ignoring
Range
andString
types for now since they're in flux.