From the Swift documentation:
"If you define an optional variable without providing a default value,
the variable is automatically set to nil for you."
* Private members may not satisfy protocol requirements, ever.
...because by construction they can be invoked from outside of the
type.
Finishing up SE-0025 ('private' and 'fileprivate').
* Update docs and mark SE-0025 ('private' and 'fileprivate') as done!
There's still improvements we can make (see 508e825f), but the feature
is in place and should be working correctly.
We can express the same using the `isUniquelyReferencedNonObjC` API.
- Rename `isUniquelyReferencedNonObjC` to `isKnownUniquelyReferenced`.
- Cleanup `ManagedBufferPointer` by removing holdsUniqueOrPinnedReference` and
renaming `holdsUniqueReference` to `isUniqueReference`.
- No longer promise to return false from `isKnownUniquelyReferenced` for @objc
class instances.
SR-1962
rdar://21886410
and provide a fix-it to move it to the new location as referenced
in SE-0081.
Fix up a few stray places in the standard library that is still using
the old syntax.
Update any ./test files that aren't expecting the new warning/fix-it
in -verify mode.
While investigating what I thought was a new crash due to this new
diagnostic, I discovered two sources of quite a few compiler crashers
related to unterminated generic parameter lists, where the right
angle bracket source location was getting unconditionally set to
the current token, even though it wasn't actually a '>'.
All generic bridgeable types can bridge for all their instantiations now. Removing this ferrets out some now-unnecessary traps that check for unbridgeable parameter types.
Foundation provides a number of specific operators defined in the
global scope. Push all of these into their corresponding types. This
cleanup helps verify that the SE-0091 implementation is generally
functional.
Safely unwrap two optionals used in the compare that follows.
NFC, but this (or another work-around) will be required if either
SE-0121 or SE-0123 is approved.
Concurrently with the development of struct IndexSet, the stdlib team
was busy reworking the way that all indexes in collections worked
(https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md).
Both efforts landed at basically the same time. We did the minimum
possible to adopt the new indexing model when IndexSet landed. This
change more correctly adopts the new model.
In summary, the new model has the Collection change the value of the
Index, instead of the Index changing the value on its own. Previously,
the Index had methods like successor(), but now the Collection has
methods like index(after:). This means that the index no longer has to
store a reference to the collection in many cases, which means that CoW
semantics can kick in far more often as the index is a dead simple model
object that just stores a bunch of integers. So basically, this change
moves all the logic for moving indexes from Index into IndexSet.
<rdar://problem/26269319> More fully adopt new indexing model for better performance in IndexSet
The Swift 3 refactoring of the range type has led to its split into 4
different types. The IndexSet API should accept any of these as long as
they contain the element type (Int, which is inherently Countable). This
allows callers to use both the ... and ..< syntax, for example.
This commit also adds additional unit tests for some of the IndexSet
API, and turns a few methods with optional/default args into properties
or a method family, since otherwise callers would end up with an
ambigious method call as the range argument would have been defaulted to
nil.
<rdar://problem/26532614> Add overloads for range types to IndexSet
