* 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.
* 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.
When we process a constraint, the first step is generally to call
getFixedTypeRecursive() to look through type variables. When this
operation actually does non-trivial work, we could save
that result by considering the current constraint "solved" and
generating a new constraint (if needed!) with the simplified types.
This commit adds the infrastructure to do that, because it's important
when getFixedTypeRecursive() starts performing more interesting
substitutions (e.g., handling member types of type
variables). However, enabling for the common case of looking through a
type variable isn't profitable (it's ~2% slower to type-check the
standard library). Stage in this infrastructure change now.
Implements part of SE-0110. Single argument in closures will not be accepted if
there exists explicit type with a number of arguments that's not 1.
```swift
let f: (Int, Int) -> Void = { x in } // this is now an error
```
Note there's a second part of SE-0110 which could be considered additive,
which says one must add an extra pair of parens to specify a single arugment
type that is a tuple:
```swift
let g ((Int, Int)) -> Void = { y in } // y should have type (Int, Int)
```
This patch does not implement that part.
- Any is made into a keyword which is always resolved into a TypeExpr,
allowing the removal of the type system code to find TheAnyType before
an unconstrained lookup.
- Types called `Any` can be declared, they are looked up as any other
identifier is
- Renaming/redefining behaviour of source loc methods on
ProtocolCompositionTypeRepr. Added a createEmptyComposition static
method too.
- Code highlighting treats Any as a type
- simplifyTypeExpr also does not rely on source to get operator name.
- Any is now handled properly in canParseType() which was causing
generic param lists containing ‘Any’ to fail
- The import objc id as Any work has been relying on getting a decl for
the Any type. I fix up the clang importer to use Context.TheAnyType
(instead of getAnyDecl()->getDeclaredType()). When importing the id
typedef, we create a typealias to Any and declare it unavaliable.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
This documentation revision covers a large number of types & protocols:
String, its views and their indices, the Unicode codec types and protocol,
as well as Character, UnicodeScalar, and StaticString, among others.
This also includes a few small changes across the standard library for
consistency.
