Even though it doesn't conform to RandomAccessIndexType without
Foundation loaded, we can implement these internal operations to happen
in O(1), which, e.g., should speed up count(s.utf16) among others.
Swift SVN r24009
There had been some discussion of making this available iff Foundation
is loaded, but it turns out that there are almost no Foundation APIs
that return NSUInteger indices into NSStrings without first packaging
them into NSRanges, and when <rdar://problem/19255291> is addressed,
these NSRanges will become Swift Range's, which have a different
interface. So there's no seamless API transition to be had here, for
any substantial subset of code written against Cocoa.
Swift SVN r23949
Rather than expose random access on String.UTF16View to all Swift users,
expose it only when Foundation is loaded. This effectively decouples
String from a UTF16 representation on non-Mac platforms.
Swift SVN r23929
We don't want to be locked into a UTF-16 representation on all
platforms, and when we implement String index conversion we really don't
want to extend the interface of Int.
Swift SVN r23928
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
Keep calm: remember that the standard library has many more public exports
than the average target, and that this contains ALL of them at once.
I also deliberately tried to tag nearly every top-level decl, even if that
was just to explicitly mark things @internal, to make sure I didn't miss
something.
This does export more than we might want to, mostly for protocol conformance
reasons, along with our simple-but-limiting typealias rule. I tried to also
mark things private where possible, but it's really going to be up to the
standard library owners to get this right. This is also only validated
against top-level access control; I haven't fully tested against member-level
access control yet, and none of our semantic restrictions are in place.
Along the way I also noticed bits of stdlib cruft; to keep this patch
understandable, I didn't change any of them.
Swift SVN r19145
-Hide vars that have a private type.
-Hide functions that have a parameter with private type or a parameter name with leading underscore.
-Minor change in StringUTF16.swift to avoid printing "func generate() -> IndexingGenerator<_StringCore>".
rdar://17027294
Swift SVN r18623
