{"id":2876,"date":"2014-07-26T14:08:17","date_gmt":"2014-07-26T17:08:17","guid":{"rendered":"http:\/\/brockerhoff.net\/blog\/?p=2876"},"modified":"2014-08-06T20:37:05","modified_gmt":"2014-08-06T23:37:05","slug":"swift-learning-about-type-constraints","status":"publish","type":"post","link":"https:\/\/brockerhoff.net\/blog\/2014\/07\/26\/swift-learning-about-type-constraints\/","title":{"rendered":"Swift: learning about type constraints"},"content":{"rendered":"

My first reading of the Swift books and of the generated Swift library header (remember, you can see the header by command-double-clicking on any Swift type) left me quite confused about the proper way to write generics and extensions to generics.<\/p>\n

As usual, I favor learning-by-doing for such things [skydiving joke omitted]<\/em> \u2014 I paged through a book on \u201cType Theory\u201d to no avail \u2014 so, in a recent update to my SwiftChecker app<\/a> I tried to include a useful extension.<\/p>\n

Here is a (slightly edited) part of it:<\/p>\n

public extension Dictionary {\r\n\t\/**\tMerges a sequence of values into a Dictionary by specifying\r\n\t\ta filter function. The filter function can return nil to filter\r\n\t\tout that item from the input Sequence, or return a (key,value)\r\n\t\ttuple to insert or change an item. In that case, value can be\r\n\t\tnil to remove the item for that key. *\/\r\n\tmutating func merge <T, S: SequenceType where S.Generator.Element == T>\r\n\t\t(seq: S, filter: (T) -> (Key, Value?)?) {\r\n\t\tvar gen = seq.generate()\r\n\t\twhile let t: T = gen.next() {\r\n\t\t\tif let (key: Key, value: Value?) = filter(t) {\r\n\t\t\t\tself[key] = value\r\n\t\t\t}\r\n\t\t}\r\n\t}\r\n}\t\/\/ end of Dictionary extension<\/code><\/pre>\n
To explain this, first recall that types can include typealias<\/code> declarations within their definitions; this is much used for generic types, but can also be used everywhere. Here’s the declaration for Sequence<\/code> from the library header:<\/p>\n
protocol SequenceType : _Sequence_Type {\r\n    typealias Generator : GeneratorType\r\n    func generate() -> Generator\r\n}\r\n<\/code><\/pre>\n
and of the GeneratorType<\/code> protocol it uses:<\/p>\n
protocol GeneratorType {\r\n    typealias Element\r\n    mutating func next() -> Element?\r\n}\r\n<\/code><\/pre>\n
Going backwards: the GeneratorType<\/code> protocol defines an associated type with the typealias<\/code> declaration, in this case, Element<\/code>. This is a placeholder type that will become an actual type when the protocol is adopted. These associated types form a hierarchy, so that you can refer to GeneratorType.Element<\/code> and, further up, to Sequence.Generator.Element<\/code>, and so forth.<\/p>\n
Now look again at the merge<\/code> method I define in my extension to Dictionary<\/code>:<\/p>\n
\tmutating func merge <T, S: SequenceType where S.Generator.Element == T>\r\n\t\t(seq: S, filter: (T) -> (Key, Value?)?) { \/\/ ... etc.\r\n<\/code><\/pre>\n
Inside the <> after the method name are the type constraints. When I call merge<\/code> on a Dictionary<\/code>, this means that:<\/p>\n
    \n
  • T<\/code> is a placeholder type (with no constraints) used for the rest of the definition<\/li>\n
  • S<\/code> is another placeholder that is constrained to conform to the SequenceType<\/code> protocol, and further (by using the where<\/code> clause)<\/li>\n
  • the generate()<\/code> function for S<\/code> must return a Generator<\/code> whose Element<\/code> is equal to T<\/code>, and also<\/li>\n
  • T<\/code> is inferred from the argument type of the function\/closure passed as the last argument to merge<\/code>, and finally<\/li>\n
  • this function\/closure must return an Optional<\/code> tuple of type (Key, Value?)<\/code>.<\/li>\n<\/ul>\n
    But what is this (Key, Value?)<\/code> type, then? Recall that we’re extending Dictionary<\/code>, so that type’s associated type hierarchy is also available; checking the declaration in the library header, we see:<\/p>\n
    struct Dictionary<Key : Hashable, Value> : CollectionType, DictionaryLiteralConvertible {\r\n    typealias Element = (Key, Value)\r\n    typealias Index = DictionaryIndex<Key, Value>\r\n    ... etc.\r\n<\/code><\/pre>\n
    so our type constraint will match Key<\/code>\u00a0and Value<\/code>\u00a0to those pertaining to the particular Dictionary<\/code> that merge<\/code> is being called on! To be more clear, we could even write (Dictionary.Key, Dictionary.Value?)<\/code> in our definition.<\/p>\n
    Let’s look at a specific example of that. Notice that, where in the type constraints we refer to the placeholder type names (on the left of\u00a0the\u00a0typealias<\/code>\u00a0declarations), we refer to specific types wherever one is defined.<\/p>\n
    let strs = [ \"10\", \"11\", \"12\", \"xyz\" ]\t\/\/ this is an Array  and therefore\r\n\t\t\t\t\t\/\/ its Generator.Element is String\r\nlet dict = [ 0:\"0\" ]\t\/\/ this is a Dictionary <Int, String> and therefore\r\n\t\t\t\/\/ its Key is Int and Value is String\r\ndict.merge (strs) { (s) in\t\/\/ s is inferred to be strs's Generator.Element,\r\n\t\t\t\t\/\/ that is, a String\r\n\tlet v = s.toInt()\t\/\/ v is an Optional , will be nil for \"xyz\"\r\n\treturn v ? (v!, s) : nil\t\/\/ returns a valid tuple or nil\r\n}\r\n\/\/ dict will now contain [ 0:\"0\", 10:\"10\", 11:\"11\", 12:\"12\" ]\r\n<\/code><\/pre>\n
    You can verify that everything matches our type constraints either directly or by type inference. If you change anything that doesn’t fit \u2014 say, by declaring s<\/code> as anything but String<\/code> inside the closure, or changing the type it returns \u2014 you’ll see a syntax error. (Assuming, of course, that no other extension has matching constraints.)<\/p>\n
    That said, currently (Xcode 6.0b5) the library header still has some bugs. Specifically, many type constraints either have too many prefixes removed, or show the wrong hierarchy, so you’ll see things like <S : Sequence where T == T><\/code> which won’t compile if you copy & paste it. No doubt this will be fixed soon.<\/p>\n
    Update:<\/strong> oops. Fixed the return<\/code>, above.<\/p>\n
    Update#2:<\/strong>\u00a0updated for Xcode 6.0b5 \u2014 many of those typenames either lost or gained a Type<\/code>\u00a0suffix.<\/p>\n","protected":false},"excerpt":{"rendered":"
    My first reading of the Swift books and of the generated Swift library header (remember, you can see the header by command-double-clicking on any Swift type) left me quite confused about the proper way to write generics and extensions to generics. As usual, I favor learning-by-doing for such things [skydiving joke omitted] \u2014 I paged […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[3,4,19],"tags":[47],"class_list":["post-2876","post","type-post","status-publish","format-standard","hentry","category-apple","category-dev","category-software","tag-swift"],"featured_image_src":null,"author_info":{"display_name":"Rainer Brockerhoff","author_link":"https:\/\/brockerhoff.net\/blog\/author\/rbrockerhoff\/"},"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1q3Zc-Ko","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/posts\/2876","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/comments?post=2876"}],"version-history":[{"count":0,"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/posts\/2876\/revisions"}],"wp:attachment":[{"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/media?parent=2876"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/categories?post=2876"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/brockerhoff.net\/blog\/wp-json\/wp\/v2\/tags?post=2876"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}