Some time ago, it was pointed out that "truncating" would be used only for bit pattern operations. As pointed out on Swift Evolution, this is the only spot where the same term is used for dropping the fractional part of a floating point value; elsewhere, it is always spelled--even in documentation--as "rounded toward zero." This PR updates the usage here to align with existing convention.
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.
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>
It looks like the compiler is having troubles with the pattern when the
non-mutaing operator is defined on the protocol, and delegates to the
mutating version, that is provided by the concrete type. Adding similar
definitions of non-mutating operators to concrete types significantly
speeds up the typechecking of complex expressions, like the one in
the ByteSwap benchmark.
This speeds up construction of a String from large Character representations,
and various other operations that would otherwise require additional grapheme
breaking just to interpret the Character.
- remove additional 'characters' references from String docs
- improved language around escaping pointer arguments
- key path type abstracts
- codable type abstract revisions
- a few more NSString API fixes
Adds in Linux platform support for our pthread TLS. Replace usage of
PTHREAD_KEYS_MAX with a sentinel value, as it's tricky to define
cross-platform and was only lightly used inside sanity checks.
Use UBreakIterators to perform grapheme breaking. This gives Unicode 9
grapheme breaking (e.g. family emoji) and provides a means to upgrade
to future versions. It also serves as a model for how to serve up
other advanced functionality in ICU to users.
This has tricky performance implications. Some things are faster and a
number of cases are slower. But, careful use of ICU can help mitigate
and amortize these costs. In conjunction with more early detection of
fast paths, overall grapheme breaking for the average user should be
much faster than in Swift 3.
NOTE: This is incomplete. It currently falls back on the legacy tries
for some bridged strings. There are many potential directions for a
general solution, but for now we'll be interatively adding support for
more and more special cases.
Introduces a _ThreadLocalStorage struct to hold thread-local, but
global resources. Set it up to host a UBreakIterator and a cache key
for resetting text.
UBreakIterators are extremely expensive to create on the fly, so we
store one for each thread. UBreakIterators are also expensive to bind
to new text, so we cache the text it's currently bound to in order to
help avoid it.
The struct can be expanded with more functionality in the future, but
the standard library should only ever use a single key, and thus
everything should go on this struct. The _ThreadLocalStorage struct is
not meant to be copyable, creatable (by anyone else except the
once-per-thread initialize routine), and should accessed through the
pointers it provides.
Future immediate directions could include cashing multiple
UBreakIterators (e.g. avoid a text reset for mutual character
iteration patterns, etc).
Test added in test/stdlib/ThreadLocalStorage.swift.
Introduce shims for using UBreakIterators from ICU. Also introduce
shims for using thread local storage via pthreads.
We will be relying on ICU and UBreakIterators for grapheme
breaking. But, UBreakIterators are very expensive to create,
especially for the way we do grapheme breaking, which is relatively
stateless. Thus, we will stash one or more into thread local storage
and reset it as needed.
Note: Currently, pthread_key_t is hard coded for a single platform
(Darwin), but I have a static_assert alongside directions on how to
adapt it to any future platforms who differ in key type.
Having such a builtin makes it easier for the optimizer to reason about what is actually happening.
I plan to add later some optimizations which can optimize pieces of code dominated by such a check.
