The overhead of the weak reference overwhelms the savings from
avoiding the setText, when there's a fair amount of reference counting
involved. The real solution will be to use an unowned reference. For
now, drop the cache and introduce it once we have more runtime
functionality.
* Adds conformance of Optional to Codable
* encode(...) arguments are no longer Optional; Optional values go
through generic version
* encodeIfPresent added to KeyedEncodingContainerProtocol to mirror
decodeIfPresent
* JSONEncoder and PropertyListEncoder updated to reflect these changes
A `Character` _should_ contain only a single grapheme, but we can't formally require it because of grapheme cluster literals and the shifting sands of Unicode. Fixes https://bugs.swift.org/browse/SR-4955
_DropFirstSequence, _PrefixSequence and _DropWhileSequence as structs.
I turns out we DON’T require reference semantics to keep track of how many elements we've already taken from the underlying sequence.
… that’s taken care of by the underlying sequence, which has to have reference semantics if it needs them.
It was always testing `rhs` against `rhs`, so it could never fail. But
we don't actually need the test at all, because the `value` field is
sufficient to compare indices.
Programs using a statically linked build of the standard library need
to explicitly link against icucore. There are various potential
hacks^Wsolutions to this problem, and this is an attempt at a lesser
of evils approach.
Emit a linker directive to perform autolinking against icucore on
Darwin systems. This allows us to avoid hacking the compiler driver
and propagating that hack onto any build systems that don't go through
the driver.
These were supposed to help during the early days of Swift 3, when our
omission of needless words was being tempered by framework authors'
explicitly-specified names in API notes...but they were accidentally
not made public, and no one noticed. After checking with the AppKit
team, we decided to just drop them.
This overload allows `String.filter` to return a `String`, and not
`[Character]`.
In the other hand, introduction of this overload makes `[123].filter`
somewhat ambiguous in a sence, that the compiler will now prefer an
implementatin from a more concrete protocol, which is less efficient for
arrays, therefore extra work is needed to make sure Array types fallback
to the `Sequence.filter`.
Implements: <rdar://problem/32209927>
