calls over arrays created from array literals. This enables optimizing
further the output of the OSLogOptimization pass, and results in
highly-compact and optimized IR for calls to the new os log API.
<rdar://58928427>
* [stdlib] Update complexity docs for seq/collection algorithms
This corrects and standardizes the complexity documentation for Sequence
and Collection methods. The use of constants is more consistent, with `n`
equal to the length of the target collection, `m` equal to the length of
a collection passed in as a parameter, and `k` equal to any other passed
or calculated constant.
* Apply notes from @brentdax about complexity nomenclature
* Change `n` to `distance` in `index(_:offsetBy:)`
* Use equivalency language more places; sync across array types
* Use k instead of n for parameter names
* Slight changes to index(_:offsetBy:) discussion.
* Update tests with new parameter names
We would like to eventually extend Array, Dictionary, and Set to support move-only element types when the language does. To that end, we need to get the `consuming`-ness of protocol requirements on Sequence, Collection, and related protocols right for forward compatibility so that a future version of Swift that extends these types to support move-only data structures remains ABI- and API-compatible with older versions of the language. Mark requirements as `__consuming` where it would be necessary for a move-only implementation of one of these types.
In theory there could be a "fixed-layout" enum that's not exhaustive
but promises not to add any more cases with payloads, but we don't
need that distinction today.
(Note that @objc enums are still "fixed-layout" in the actual sense of
"having a compile-time known layout". There's just no special way to
spell that.)
Addressed ABI FIXME’s #4, #5, #104 and #105, making Sequence’s
SubSequence conform to Sequence, with the same element type, and for
which the SubSequence of a SubSequence is the same SubSequence.
Fixes SR-318 / rdar://problem/31418206.
Addressed ABI FIXME’s #4, #5, #104 and #105, making Sequence’s
SubSequence conform to Sequence, with the same element type, and for
which the SubSequence of a SubSequence is the same SubSequence.
Fixes SR-318 / rdar://problem/31418206.
_DropFirstSequence, _PrefixSequence and _DropWhileSequence as structs.
I turns out we DON’T require reference semantics to keep track of how many elements we've already taken from the underlying sequence.
… that’s taken care of by the underlying sequence, which has to have reference semantics if it needs them.
This overload allows `String.filter` to return a `String`, and not
`[Character]`.
In the other hand, introduction of this overload makes `[123].filter`
somewhat ambiguous in a sence, that the compiler will now prefer an
implementatin from a more concrete protocol, which is less efficient for
arrays, therefore extra work is needed to make sure Array types fallback
to the `Sequence.filter`.
Implements: <rdar://problem/32209927>
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
* removing .characters from examples
* beginning new String doc revisions
* improvements to the String Foundation overlay docs
* minor revisions elsewhere
Eliminate all of the redundant conformance constraints in the standard
library that were identified by the newly-introduced warning for
redundant, explicitly-specified conformances.
Calling drop(while: ) after prefix() on a pure Sequence loses the
prefix, because in the internal drop(while: ) override grabs the
underlying base iterator from _PrefixSequence and wraps it in a
_DropWhileSequence.
