{"id":13405,"date":"2016-02-02T14:36:41","date_gmt":"2016-02-02T19:36:41","guid":{"rendered":"http:\/\/mjtsai.com\/blog\/?p=13405"},"modified":"2016-02-02T14:36:41","modified_gmt":"2016-02-02T19:36:41","slug":"seven-swift-snares","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2016\/02\/02\/seven-swift-snares\/","title":{"rendered":"Seven Swift Snares"},"content":{"rendered":"

David Ungar<\/a> (comments<\/a>):<\/p>\n

\n

But with value types, there’s no override<\/code> keyword to help the compiler find my mistakes. This omission seems out of place in a language otherwise designed to include enough redundancy to help find one’s errors.<\/p>\n

[…]<\/p>\n

All that can be known at compile-time is that pie is a Pizza<\/code>, and the Pizza<\/code> protocol extension says Wheat, so the declaration of a cornmeal crust in the CornmealPizza<\/code> structure had no effect whatsoever when asking pie for something. Although the compiler could have warned about the potential for error from this use of static- instead of dynamic-dispatch, it did not. I believe that here lurks a trap for the unwary, and I would call this a major snare<\/strong>.<\/p>\n

[…]<\/p>\n

Presenting Swift with both a declaration and a definition in this fashion causes the compiler to take notice of the runtime value of the pie variable.<\/p>\n

[…]<\/p>\n

However, without editing the source code in the framework, we cannot fix this problem. Hence, it is impossible to safely extend a protocol declared in another framework (without gambling that it will never need dynamic-dispatch.)<\/p>\n

[…]<\/p>\n

As shown in a previous section, a declaration in a protocol was sufficient to induce dynamic dispatch for a defined<\/em> of the corresponding attribute in the protocol extension. But a definition in a restricted<\/em> extension is always statically-dispatched<\/em>.<\/p>\n

[…]<\/p>\n

Avoid assigning the result of an expression with side-effects to left-hand-side with optional chaining.<\/p>\n

[…]<\/p>\n

In-out parameters do not work when passed into the outer scope of a closure<\/p>\n<\/blockquote>\n\n

Joe Groff<\/a>:<\/p>\n

These are all things we hope to remove or provide diagnostics for in 3.0, at least.<\/p><\/blockquote>\n\n

Sam Griffith<\/a>:<\/p>\n

Swift for all its newness is going down a path much like C++ did as far as complexity. That is worrisome.<\/p><\/blockquote>\n\n

Ørta<\/a>:<\/p>\n

Swift’s init rules are confusing. I’ve never once got anything non-trivial right first time<\/p><\/blockquote>\n\n

Marcel Weiher<\/a> (tweet<\/a>, first linked in 2014<\/a>):<\/p>\n

Apple’s new Swift language has taken a page from the C++ and Java \nplaybooks and made initialization a special case. Well, lots<\/em>\nof special cases actually. The Swift book has 30 pages<\/em> on\ninitialization, and they aren’t just illustration and explanation,\nthey are dense with rules and special cases.<\/p><\/blockquote>\n\n

Joe<\/a> Groff<\/a>:<\/p>\n

The initializer model does need reconsideration, though. Current model doesn’t fit our ABI resilience goals.<\/p><\/blockquote>\n

A little up-front complexity for initializers greatly simplifies the state space for everything else.<\/p><\/blockquote>","protected":false},"excerpt":{"rendered":"

David Ungar (comments): But with value types, there’s no override keyword to help the compiler find my mistakes. This omission seems out of place in a language otherwise designed to include enough redundancy to help find one’s errors. […] All that can be known at compile-time is that pie is a Pizza, and the Pizza […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"","apple_news_api_id":"","apple_news_api_modified_at":"","apple_news_api_revision":"","apple_news_api_share_url":"","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[4],"tags":[46,71,901],"class_list":["post-13405","post","type-post","status-publish","format-standard","hentry","category-programming-category","tag-languagedesign","tag-programming","tag-swift-programming-language"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/13405","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=13405"}],"version-history":[{"count":1,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/13405\/revisions"}],"predecessor-version":[{"id":13406,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/13405\/revisions\/13406"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=13405"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=13405"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=13405"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}