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
init
s rather than static functions. - The
ArrayBoundType
protocol is gone, and the various integer types that conformed to it no longer do. - The
CharacterLiteralConvertible
protocol is gone.Character
never appeared to conform to it – it conformed toExtendedGraphemeClusterLiteralConvertible
which remains. - The
StringElementType
protocol is gone, andUInt8
andUInt16
no longer conform to it. TheUTF16.copy
method, that relied on it to do some pointer-based manipulation, is also gone. - Dictionary’s initializer that took a
minimumCapacity
argument 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 aninit()
and aninit(arg: Int = 0)
) you’d get a compiler error when you tried to actually useinit()
. - In extending
RandomAccessIndexType
, integers now use theirDistance
typealias forInt
rather than straightInt
. - The static
from()
methods on integers are all gone. - There’s now an
EnumerateSequence
that returns anEnumerateGenerator
, andenumerate()
returns that rather than the generator. - The various integer types no longer have initializers from
Builtin.SomeType
. - The
_CocoaArrayType
protocol (as used to initialize anArray
from a Cocoa array) has been renamed to_SwiftNSArrayRequiredOverridesType
. - Numerous
_CocoaXXX
and_SwiftXXX
protocols have acquired an@objc
attribute. _PrintableNSObjectType
(which wasn’t explicitly implemented by anything in the std lib) is gone.- The
AssertStringType
andStaticStringType
protocols are gone, as hasAssertString
.StaticString
still exists and is clearly described as a static string that can be known at compile-time. assert
andprecondition
are much simplified with those string types removed, leaving one version each that just usesString
for it’s message parameter.assertionFailure
,preconditionFailure
andfatalError
all take aString
for their message now as well, though they still takeStaticString
for the filename argument as described in the Swift blog’s article.- There are two new
sort
functions that operate on aContiguousArray
(one for arrays of comparable elements, and one that takes a comparison predicate). - But there are two fewer
sorted
functions. The ones that take aMutableCollectionType
, 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
unsafeDowncast
that is equivalent tox as T
but with the safeties removed – to be used only when usingas
is 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
Optional.map
actually does.
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.
Some examples:
- Naming arguments in protocols instead of just using ‘
_
‘ e.g.func distanceTo(other: Self)
instead offunc 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.extend
has renamed its argument tonewElements
. - Replacing
newValues
withnewElements
in various places, presumably because of the unintended Swift implications of the term “values”. - Avoiding
i
orv
such assubscript(position: Index)
instead ofsubscript(i: Index)
, andinit(_ other : Float)
instead ofinit(_ v : Float)
. - Descriptive names for predicate arguments, such as
isOrderedBefore
rather than justpred
.
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 Array
and 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
, since 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.
Above 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? ↩
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 […]