* Make Range conditionally a Collection
* Convert ClosedRange to conditionally a collection
* De-gyb Range/ClosedRange, refactoring some methods.
* Remove use of Countable{Closed}Range from stdlib
* Remove Countable use from Foundation
* Fix test errors and warnings resulting from Range/CountableRange collapse
* fix prespecialize test for new mangling
* Update CoreAudio use of CountableRange
* Update SwiftSyntax use of CountableRange
* Restore ClosedRange.Index: Hashable conformance
* Move fixed typechecker slowness test for array-of-ranges from slow to fast, yay
* Apply Doug's patch to loosen test to just check for error
* Remove a bunch of Default(Bidirectional|RandomAccess)Indices usage from stdlib and test
* Remove some DefaultRandomAccessIndices and IndexDistance usage from Foundation
* Remove no-longer-used internal type in Existentials.swift
* Get rid of indicesForTraversal
* Eradicate IndexDistance associated type, replacing with Int everywhere
* Consistently use Int for ExistentialCollection’s IndexDistance type.
* Fix test for IndexDistance removal
* Remove a handful of no-longer-needed explicit types
* Add compatibility shims for non-Int index distances
* Test compatibility shim
* Move IndexDistance typealias into the Collection protocol
Make the Indices types conform to the appropriate Collection protocol:
* Collection.Indices: Collection
* BidirectionalCollection.Indices: BidirectionalCollection
* RandomAccessCollection.Indices: RandomAccessCollection
Introduce (recursive) constraints that make the *Collection constraint
of SubSequence match that of its enclosing *Collection, e.g.,
MutableCollection.SubSequence conforms to MutableCollection.
Fixes rdar://problem/20715031 and more of SR-3453.
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.
* Unify the capitalization across all user-visible error messages (fatal errors, assertion failures, precondition failures) produced by the runtime, standard library and the compiler.
* Update some more tests to the new expectations.
* 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
Part of ABI FIXME #99, this gives us some nice consistency that
ensures that slicing a SubSequence gives us another SubSequence. There
are two source-compatibility implications to this change:
* Collections now need to satisfy this property, which could not be
expressed in Swift 3. There might be some Collections that don't
satisfy this property, and will break with the Swift 4 compiler
*even in Swift 3 compatibility mode*. Case in point...
* The Lazy collection types were formulated as a lazy collection of
the base slice (e.g., LazyCollection<ArraySlice<T>>) rather than as
a slice of the lazy collection (e.g.,
Slice<LazyCollection<Array<T>>). The former doesn't meet the new
requirements, so change to the latter.
Address ABI FIXME #68 by using same-type constraints directly on an
associated type to describe the requirements on the Indices associated
type of the Collection protocol. ABI FIXMEs #89, #90, #91 are all in
StdlibUnittest, and provoke warnings once #68 is fixed, but it's nice
to clear them out.
Fixes SR-2121.
- If a parameter type is a sugared function type, mark the type
as non-escaping by default. Previously, we were only doing this
if the parameter type was written as a function type, with no
additional sugar.
This means in the following cases, the function parameter type
is now non-escaping:
func foo(f: ((Int) -> Void))
typealias Fn = (Int) -> Void
func foo(f: Fn)
- Also, allow @escaping to be used in the above cases:
func foo(f: @escaping ((Int) -> Void))
typealias Fn = (Int) -> Void
func foo(f: @escaping Fn)
- Diagnose usages of @escaping in inappropriate locations, instead
of just ignoring them.
It is unfortunate that sometimes we end up desugaring the typealias,
but currently there are other cases where this occurs too, such as
qualified lookpu of protocol typealiases with a concrete base
type, and generic type aliases. A more general representation for
sugared types (such as an AttributedType sugared type) would allow
us to solve this in a more satisfactory manner in the future.
However at the very least this patch factors out the common code
paths and adds comments, so it shouldn't be too bad going forward.
Note that this is a source-breaking change, both because @escaping
might need to be added to parameters with a sugared function type,
and @escaping might be removed if it appears somewhere where we
do not mark function types as non-escaping by default.
Adds an explicit @escaping throughout the standard library, validation
test suite, and tests. This will be necessary as soon as noescape is
the default for closure parameters.
