[Design RFC] Providing a guided landing for unwrapping outcomes

How would you provide code-level guaranteed unwrap documentation? I have a proposal in-queue for an unwrap-or-die operator. This proposal follows on to numerous forum and mailing list discussions.

I am taking a straw poll regarding some alternate designs put forth by the Swift Evolution community. Per @Douglas_Gregor’s request, I am bringing that discussion from the pull request to the forums. I would appreciate your feedback on these designs.

Thank you in advance.

1 Like

Is there any interest in deprecating ! in favor of some longer (syntactically saltier) spelling?

Java made the same mistake, in having a very short and simple name Optional.get for such a dangerous operation. One of the guys behind the design expressed his regret in some stackoverflow post IIRC, and said that in retrospect, they should have named it something like Optional.getOrThrowSomeKindOfException.

Is there any interest in respelling ! as .unsafeForceUnwrapOrDie, or anything like that?

I like and use ! in many circumstances, especially for non-production code. Using ! is not wrong in the right circumstances and I’d hate to lose it.

6 Likes

I agree with Erica. I have found many instances where conditionally unwrapping would be lead to ugly code, but where a not-nil check suffices to guarantee that unwrapping will succeed. Absent compiler bugs.

When setting up conditions for unit tests, I explicitly want the "die" behavior if something unexpected happens, so I use "!" a lot in these cases, and would hate to have to use something much noisier making my already verbose test code even harder to read.

2 Likes

fail seems best, especially if we can land Never as a bottom type so that fail could just return Never

1 Like