The biggest deal in this latest beta is the documentation. There are 2,745 new lines of
/// comments in beta 3, and even pre-existing documentation for most items has been revised.
That doesn’t mean there aren’t any functional changes to the library, though. Here’s a rundown of what I could find:
- As mentioned in the release notes, the various literal convertible protocols are now implemented as
inits rather than static functions.
ArrayBoundTypeprotocol is gone, and the various integer types that conformed to it no longer do.
CharacterLiteralConvertibleprotocol is gone.
Characternever appeared to conform to it – it conformed to
StringElementTypeprotocol is gone, and
UInt16no longer conform to it. The
UTF16.copymethod, that relied on it to do some pointer-based manipulation, is also gone.
- Dictionary’s initializer that took a
minimumCapacityargument no longer has a default for that minimum capacity. It’s interesting that this worked previously, since if you did the same thing with your own type (i.e. gave it both an
init(arg: Int = 0)) you’d get a compiler error when you tried to actually use
- In extending
RandomAccessIndexType, integers now use their
Intrather than straight
- The static
from()methods on integers are all gone.
- There’s now an
EnumerateSequencethat returns an
enumerate()returns that rather than the generator.
- The various integer types no longer have initializers from
_CocoaArrayTypeprotocol (as used to initialize an
Arrayfrom a Cocoa array) has been renamed to
_SwiftXXXprotocols have acquired an
_PrintableNSObjectType(which wasn’t explicitly implemented by anything in the std lib) is gone.
StaticStringTypeprotocols are gone, as has
StaticStringstill exists and is clearly described as a static string that can be known at compile-time.
preconditionare much simplified with those string types removed, leaving one version each that just uses
Stringfor it’s message parameter.
fatalErrorall take a
Stringfor their message now as well, though they still take
StaticStringfor the filename argument as described in the Swift blog’s article.
- There are two new
sortfunctions that operate on a
ContiguousArray(one for arrays of comparable elements, and one that takes a comparison predicate).
- But there are two fewer
sortedfunctions. The ones that take a
MutableCollectionType, and return one, are gone. Seems a shame, though it didn’t really make sense for them to take a mutable type given they didn’t need to mutate it. Maybe they’ll be replaced with versions that return ExtensibleCollectionType.
- There’s a new
unsafeDowncastthat is equivalent to
x as Tbut with the safeties removed – to be used only when using
asis causing performance problems.
- Raise a glass for the snarky “Haskell’s fmap, which was mis-named” comment, which is now replaced by a very straight-laced description of what
In keeping with the documenting theme, there are a lot of argument name changes here as well. Continuing a trend seen in previous betas, specific, descriptive argument names are preferred over more generic ones. This is probably a good Swift style tip for your own code, especially if you’re also writing libraries.
- Naming arguments in protocols instead of just using ‘
func distanceTo(other: Self)instead of
func distanceTo(_: Self)(there’s no compulsion to use the same names for your method arguments that the protocol does but you probably should)
- Avoiding just naming the variable after the type (e.g.
sequence: Sequence), For example,
Array.extendhas renamed its argument to
newElementsin various places, presumably because of the unintended Swift implications of the term “values”.
subscript(position: Index)instead of
subscript(i: Index), and
init(_ other : Float)instead of
init(_ v : Float).
- Descriptive names for predicate arguments, such as
isOrderedBeforerather than just
Rather than me regurgitate the comments here, I’d suggest option-clicking
import Swift and reading through it in full. There’s lots of informative stuff in there. Major types like
String have long paragraphs in front of them with some good clarifications. Many things are explained that you’d otherwise only have picked up on by watching the developer forums like a hawk.1
Here are a few items of specific interest:
The comment above
GeneratorType has been revised. The suggestion that if using a sequence multiple times the algorithm “should probably require
CollectionType implies multi-pass” is gone. Instead it states that “any code that uses multiple generators (or
for ... in loops) over a single sequence should have static knowledge that the specific sequence is multi-pass”. The most common case of having that static knowledge being that you got the sequence from a collection I guess.
Slice we find “Warning: Long-term storage of
Slice instances is discouraged“. It makes it pretty clear
Slice is mainly there to help pass around subranges of arrays, rather than being a standalone type in its own right. They give you the value type behaviour you’d get from creating a new array (i.e. if a value in the original array is changed, the value in the slice won‘t) while allowing you to get the performance benefits of copy-on-write for a sub-range of an existing array.
Several of the
_SomeProto versions of protocols now have an explicit comment along the lines of the previously implied “this protocol is an implementation detail of
SomeProto; do not use it directly”. I’m still not sure why these protocols are written in this way, possibly as a workaround for some compiler issues? If you have an idea, let me know.
edit: a post on the dev forum confirms it’s a temporary workaround for a compiler limitations related to generics, though doesn’t get specific about what limitation. Thanks to @anatomisation and @ivicamil for the link.
The reason for
ContiguousArray’s existence is finally made clear. It’s there specifically for better performance when holding references to classes (not value types). There’s also a comment above the various collection
withUnsafeBufferPointer methods suggesting you could use them when the optimizer fails to eliminate bounds checks automatically, in a performance-vs-safety trade-off.
Chris Lattner clarified on the dev forum that although this version is a GM, that’s in order to allow you to use it to submit apps to the mac store rather than because this is the final shipping version. We’ll likely see more changes to Xcode 6.1 before that, and with it maybe further changes to the standard lib.
- Or reading this blog, of course. Hopefully the comments don’t get too helpful, what would I write about then? ↩
4 thoughts on “Changes to the Swift Standard Library in 1.1 beta 3”
Tried to post this on twitter, but it’s either broken or they’re spam filtering me, because I can’t find it in search or see it in mentions https://twitter.com/anatomisation/status/517120261934841856
Anyway, see https://devforums.apple.com/message/1023415#1023415 for the word on _Protocols.
I don’t understand your example for “Avoiding i and v”. Is there a cut and paste error or am I too dumb?
Not too dumb, my bad! It was part cut-paste error (for the first one) and wordpress messing with me (for the second one). Thanks for the spot, should be fixed now.
[…] airspeedvelocity.net – Changes to the Swift Standard Library in 1.1 beta 3 […]