First of all, this review thread is a trainwreck. I hope the Core Team remains committed to fostering a positive community. They shouldn’t feel alone in this challenge; everyone must play a part. Proposals shouldn’t feel like a slog and their authors shouldn’t feel put-upon in chasing them. I’m not the only user who’s followed the forums less closely because of its vitriol.
My feeling on this proposal is a tentative +1. I've followed the proposal since its inception, and strongly feel it is a problem worth solving in Swift.
There are a couple of issues wrapped up in this discussion, and in addressing this proposal the Core Team should seek to improve upon them all.
-
Tooling. The simplest Fix-It in the world is adding an
!
, and it being incorrect makes it no less attractive. -
Learnability.
preconditionFailure
andfatalError
just aren't going to come up in a beginner Swift course. I've tried to squeeze them in, and I just get blank stares. It is not an excuse to say "just learn them". They look scary because they are scary. They "crash" and "crashing is bad". -
Reporting. Some feel that it's hard to locate the source of a failed unwrap, in optimized code but in debug mode too. Particularly for a newbie, a spare
ud2
in one of Apple's sanitized crash logs does not always clearly point to the problem.
If the Core Team can provide meaningful improvements w.r.t. the above, then more sigils in the stdlib aren't needed. Either way this proposal should be taken seriously: there are limitations to operator functions that prevent an implementation of !!
from being useful in client code, and they should be lifted.