{"id":16946,"date":"2017-01-13T13:57:27","date_gmt":"2017-01-13T18:57:27","guid":{"rendered":"http:\/\/mjtsai.com\/blog\/?p=16946"},"modified":"2020-04-21T13:49:20","modified_gmt":"2020-04-21T17:49:20","slug":"swift-3-protocols","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2017\/01\/13\/swift-3-protocols\/","title":{"rendered":"Swift 3 Protocols"},"content":{"rendered":"

Brent Simmons<\/a>:<\/p>\n

\n

I first learned protocol-oriented-programming with Objective-C, and I was very pleased to see the Swift team emphasize this style.<\/p>\n

But, at least at this writing at the end of 2016, I still run into problems when I use this style of programming in Swift.<\/p>\n<\/blockquote>\n\n

Dave Abrahams<\/a>:<\/p>\n

Protocols (a.k.a. concepts) are not just bags of syntax; unless you can attach semantics to the operations, you can’t write useful generic algorithms against them. So we shouldn’t have DefaultConstructible<\/code> for the same reason we shouldn’t have “Plusable” to represent something that lets you write x + x<\/code>.<\/p><\/blockquote>\n\n

Via Ole Begemann<\/a> (tweet<\/a>):<\/p>\n

Yet, by conforming a type to Equatable<\/code> you also guarantee that your implementation follows the protocol’s semantics<\/em>, which are listed in its documentation<\/a>.<\/p>\n

[…]<\/p>\n

One problem with a generic init()<\/code> requirement without additional context is that T()<\/code> means very different things for different T<\/code>[…]<\/p>\n

[…]<\/p>\n

The fourth argument against the DefaultConstructible<\/code> protocol is that it clashes with Swift’s policy to not initialize values to “zero” or some other default. In contrast to many other languages, Swift doesn’t zero out memory for variables — the compiler forces the programmer to initialize every variable with an explicit value.<\/p><\/blockquote>\n\n

Joshua Emmons<\/a>:<\/p>\n

I’ve found these two papers particularly enlightening:<\/p>