Archive for the ‘Poll’ Category

Straw Poll: Unwrapping solutions

Swift should be able to mitigate two issues related to forced unwrapping. First, it’s used as a bandaid by developers new to the language who want to make their code compile. Second, developers should be able to provide code-level annotation support for why a guaranteed wrap cannot fail and provide runtime diagnostics in any “Black Swan” scenario where they do. These items are discussed further in this proposal.

Please let me know which of the following designs you prefer. Each contains a link to a code solution. (The first item in the list (“Unwrap or Die”) links to a full proposal so scroll down to the design section.) The other two offer alternate designs. You can assume !! can be redesigned to support both throwing and Never solutions just as easily as fail or ??. The proposal goes into detail as to why that was not the original design, as doing so fundamentally changes nil-coalescing semantics.

Thank you in advance for your feedback and/or participation in the survey.

link to poll

Survey: How would you rename associated type?

The typealias keyword is overloaded to declare two kinds of types:

  1. Type Aliases (alternative name for an existing type)
  2. Associated Types (placeholder name to type used as part of a protocol)

Proposal SE-011 declares, “These two kinds of declarations are different and should use distinct keywords. This would emphasize the difference between them and reduce some of the confusion surrounding the use of associated types.”

What keyword do you think is a better replacement for typealias? Help out in this poll.

Community responses, from the proposal:

  • “I think this is a great idea; re-using typealias for associated types was a mistake.” -John McCall
  • “Agreed.” -Chris Lattner
  • “+1 to the proposal, emphasizing the distinction is important; and I like “associated” as the keyword for this purpose, too.” -Dmitri Gribenko
  • “+1 for using a distinct keyword for associated types” -Ilya Belenkiy

If this book existed, would you buy it? (Part 2 in a series)

Remember my poll about a possible Swift Markup book? Based on your feedback and support, I went ahead and wrote it; Swift Documentation Markup is now at iTunes and from Leanpub. Thank you everyone!

So, next, how about this?


Would you buy a book about common Swift style rules? Something similar to the topics I brought up yesterday in this related post but more comprehensive, with discussion and code samples? Keep in mind this wouldn’t be a bible — just helpful, hopefully well sourced, opinions and suggestions.

A few things:

  • If there’s anything specific you’d like to see in a book or any issues you have with the ideas I throw out in my posts, please ping me and let me know.
  • Now that I’m set up over at Leanpub, I’m intrigued by their system of installment-publishing. iBooks also supports updates, revisions, and expansions. Would you be more interested in a whole-book-at-once or reading-as-I-write in general?

And finally, these are the existing books in my self-published series:

Screen Shot 2015-10-14 at 3.08.34 PM  cover