* 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
The RangeProtocol was a very weak and fragile abstraction because it
didn't specify the interpretation of the endpoints. To write a
non-trivial algorithm, one usually needed to consult that information.
The standard library code only actually worked correctly with half-open
and closed ranges (and didn't handle fully open ranges, for example).
The other two protocols, HalfOpenRangeProtocol and ClosedRangeProtocol,
were only used for code sharing, and present an ABI burden. We can use
gyb instead.
We usually don't put descriptions and mirrors into default
implementations, but these protocols are special because users are not
allowed to declare conformances to them.
- Replaced RandomAccessIndex mentions from Strideable documentation
with stronger guarantees if Stride conforms to Integer.
- Other cleanup and revisions.
Right now, the rule is that any access of a stored property from a
constructor or destructor through 'self' must go directly to storage,
skipping observers or getter/setter overrides.
This means that in particular, constructors of resilient types cannot
be @_transparent, or defined in an extension in another module.
Previously, this was only caught in IRGen when the @_transparent
function was inlined into a function from another module, which made
debugging difficult.
Now, we hit an assert in Sema in this case. Of course it should be a
diagnostic; we'll get there eventually.
We could partially lift the restriction, allowing convenience
initializers to be defined @_transparent or be added in extensions,
by having accesses of stored properties from convenience inits go
through accessors. This would be safe, because at that point, we must
already have performed a self.init() delegation, however it would
potentially break existing code in subtle ways.
Also, this patch marks the RangeIterator and Range types @_fixed_layout,
since they define @_transparent initializers and this tripped the
new assert. Furthermore, note that the @_transparent initializer
must be versioned because it is inlined into another versioned
@_transparent function.
