The BidirectionalCollection protocol has no requirements that mention
the associated type 'SubSequence', which means it cannot be easily
inferred. Duplicate the subscript requirement from Collection into
BidirectionalCollection to aid type witness inference.
Extensions of the RandomAccessCollection protocol provide two
mutually-incompatible default implementations for 'indices', one of
which uses DefaultRandomAccessIndices<Self> and the other uses
CountableRange<Index>. Type witness inference (rightly) considers the
two ambiguous, although it didn't before, causing regressions.
Remove the same-type constraint
SubSequence == DefaultRandomAccessIndices<Self>
from the most general extension, so that the more-specialized,
CountableRange version is selected when it's constraints are met, and
the most-general version is selected otherwise.
The down-side to this change is that the most-general version of
'indices', which produces a DefaultRandomAccessIndices<Self>, will be
available in all types that conform to RandomAccessCollection, even if
they have a different Indices type.
Quiz: What does @_transparent on an extension actually *do*?
1) Make all members @_transparent?
2) Allow your members to be @_transparent?
3) Some other magical effect that has nothing to do with members?
The correct answer is 1), however a few places in the stdlib defined
a @_transparent extension and then proceeded to make some or all members
also @_transparent, and in a couple of places we defined a @_transparent
extension with no members at all.
To avoid cargo culting and confusion, remove the ability to make
@_transparent extensions altogether, and force usages to be explicit.
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.
Changes:
- Native dictionary and set indices no longer hold references to storage
- Cocoa-based dictionary and set indices no longer hold references to storage
- Removed double indirection trick from hashed collections
- Rewrote storage types to reflect simpler model
- Updated unit tests
