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

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