* First draft of incorporating material from #38891
* Apply suggestions from Alex's review
Co-authored-by: Alex Martini <amartini@apple.com>
* Rephrase suggested by Alex.
* Remove redundancy re: "don't replace buffer".
* Apply changes from editorial review.
* Apply Sequence edits (a3a3ff1) to MutableCollect'n
* Remove errant space.
Co-authored-by: Guillaume Lessard <glessard@users.noreply.github.com>
Co-authored-by: Chris Adamson <cadamson@apple.com>
Co-authored-by: Alex Martini <amartini@apple.com>
Co-authored-by: Guillaume Lessard <glessard@users.noreply.github.com>
- clarify the requirement that the entire collection must be accessible
- clarify the requirement surrounding subsequences / slices
- add parameter descriptions
- specify that buffer cannot be replaced
Array’s _copyContents implementation traps if given too small a buffer. This prevents Sequence._copyContents from being used to speed up copying data into discontiguous memory. (We have to require a Collection conformance and run _copyContents on slices instead).
Document the underlying requirement.
Introduce checking of ConcurrentValue conformances:
- For structs, check that each stored property conforms to ConcurrentValue
- For enums, check that each associated value conforms to ConcurrentValue
- For classes, check that each stored property is immutable and conforms
to ConcurrentValue
Because all of the stored properties / associated values need to be
visible for this check to work, limit ConcurrentValue conformances to
be in the same source file as the type definition.
This checking can be disabled by conforming to a new marker protocol,
UnsafeConcurrentValue, that refines ConcurrentValue.
UnsafeConcurrentValue otherwise his no specific meaning. This allows
both "I know what I'm doing" for types that manage concurrent access
themselves as well as enabling retroactive conformance, both of which
are fundamentally unsafe but also quite necessary.
The bulk of this change ended up being to the standard library, because
all conformances of standard library types to the ConcurrentValue
protocol needed to be sunk down into the standard library so they
would benefit from the checking above. There were numerous little
mistakes in the initial pass through the stsandard library types that
have now been corrected.
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.
