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.
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
It is still possible to get the same behavior by providing an explicit
type context, or in a generic code, but otherwise, `String("")!` will
not compile.
* removing .characters from examples
* beginning new String doc revisions
* improvements to the String Foundation overlay docs
* minor revisions elsewhere
This adds more fast path checks for grapheme breaks between BMP
scalars. Notably the rather vast range of 0x3400–0xA4CF which includes
unified common Han ideographs as well as the first extension to
unified Han ideographs. It also happens to pick up various Yijin and
Yi symbols/radicals. Additionally, the narrow hiragana/katakana ranges
0x3041-0x3096 and 0x30A1-0x30FA (including pre-composed semi-voiced
characters but excluding the combining semi-voice marks) have fast
paths.
The net effect is that the vast majority of modern Chinese and
Japanese text should be fast-pathed. This is especially important, as
adopting Unicode 9 might otherwise pessimize performance here relative
to the tries.
A property imported from Objective-C, or marked in Swift with the `dynamic` keyword, doesn't have a vtable slot, so can't be identified that way. Use the ObjC selector as the unique identifier to ascribe equality to such components. Fixes rdar://problem/31768669. (While we're here, throw some more execution tests and a changelog note in.)
* [stdlib] Backward compatibility fix for a flatMap on [String]
Since String started to conform to Collection, the flatMap with a
sequence returning closure is now a better match that the one that
relies on the optional promotion in this code:
[""].flatMap { $0 }
which results in the default type of this expression changing from
[String] to [Character].
Restoring the old behavior in Swift 3 mode by adding a very explicit
overload.
Fixes: <rdar://problem/32024978>
* [stdlib] Fixing another compatibility issue with [String].flatMap
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.
