# SE-0217 - The "Unwrap or Die" operator **URL:** \ **Category:** Proposal Reviews\ **Created:** [June 29, 2018, 11:58pm UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107 "2018-06-29T23:58:37Z")\ **Posts on this page:** 20\ **Page:** 3
**Author:** ![svanimpe](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/svanimpe/32/38963_2.png) [@svanimpe](https://forums.swift.org/u/svanimpe)\ **Post date:** [July 1, 2018, 9:00am UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/42 "2018-07-01T09:00:17Z")
> [@Joe\_Groff](#): > > - What is your evaluation of the proposal? A strong -1. > [@Joe\_Groff](#): > > - Is the problem being addressed significant enough to warrant a change to Swift? No. To elaborate: > Examples of Real-World Use None of these use cases are able to convince me: `let event = NSApp.currentEvent!` This code clearly states that there should be an event. If the unwrap does fail, it's clearly because there's no event (for some unknown reason). `let event = NSApp.currentEvent !! "Trying to get current event for right click, but there's no event"` How is this any better? Only the obvious is stated here, but there is no clue as to the reason why there's no event. `let existing = childViewControllers as! Array ` This code clearly states that the `childViewControllers` should be `TableRowViewController`s. `let existing = childViewControllers as? Array !! "TableViewController must only have TableRowViewControllers as children"` Again, this only states the obvious, as do all the other examples in the proposal. IMHO, the use of `!!` here offers no additional value. In fact, I would actively remove it from my projects. > Encourages a thoughtful approach to unwrapping, I don't agree here, for two reasons: 1. Force unwrap should only be used when an optional can not or should not be `nil`. It should be obvious from the immediately surrounding code that this is the case. If it isn't obvious, then there's a high risk of shooting yourself in the foot and you're better off with a proper `guard` than trying to explain to yourself (or others) why it shouldn't be `nil`. 2. Just like force unwrap is misused by lazy (or beginning) programmers, so too will `!!` become a lazy (wo)man's form of error handling. I feel an explicit `guard` encourages more thought than `!!`, as it offers options. Perhaps the error isn't really an error after all and you can just log a warning and return? Perhaps the error is recoverable, should be handled by the caller and you can use throw instead? When all else fails, there's still `fatalError`. > Provides a succinct and easily-taught form for new Swift learners. As someone whose job it is to teach new learners, I can say with lots of confidence that this won't be the case. As explained above, new learners will misuse `!!` as a way to quickly print an error message, ignoring proper (thoughtful) error handling all together. > [@Joe\_Groff](#): > > - Does this proposal fit well with the feel and direction of Swift? No. As explained above, I don't feel like this proposal warrants a new operator and even risks achieving the opposite of what it's trying to do. > [@Joe\_Groff](#): > > - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? I've read the proposal and reviewed some of my projects to look for areas where this operator could add value. I found none. ---
**Author:** ![tomkeith](https://avatars.discourse-cdn.com/v4/letter/t/4491bb/32.png) [@tomkeith](https://forums.swift.org/u/tomkeith)\ **Post date:** [July 1, 2018, 10:58am UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/43 "2018-07-01T10:58:05Z")
While I admire the creativity of this proposal, I don’t think it is the right direction for Swift. Yes, writing ``` let value = wrappedValue !! “message” ``` is shorter than the equivalent ``` guard let value = wrappedValue else { fatalError(“message”) } ``` but it is also more cryptic. The “guard” version says clearly what is happening and it is easier to modify if you later decide that a fatalError is not what you want. Some people will never use this operator and it will be an impediment to comprehension when they encounter it in others’ code. ---
**Author:** ![Aciid](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/aciid/32/429_2.png) [@Aciid](https://forums.swift.org/u/Aciid)\ **Post date:** [July 1, 2018, 4:11pm UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/45 "2018-07-01T16:11:54Z")
> - What is your evaluation of the proposal? -1. IMO the motivation is not strong enough to justify addition of this operator in the stdlib. > - Is the problem being addressed significant enough to warrant a change to Swift? No, I don't think so. I doubt having a shorthand operator makes much sense in this case. I am sure it will be useful sometimes but we can always use guard, which is not a lot of extra code. > - Does this proposal fit well with the feel and direction of Swift? I think this proposal violates the fundamental API goal "Clarity is more important than brevity". The shorthand is kind of confusing because I will need to remember which method is called by this operator (precondition/fatalError). > - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? Read the proposal. ---
**Author:** ![masters3d](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@masters3d](https://forums.swift.org/u/masters3d)\ **Post date:** [July 1, 2018, 4:58pm UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/46 "2018-07-01T16:58:51Z")
> [@michael-yuji](#): > > ```swift > func Fatal(_ err: String) -> T { fatalError(err) } > > ``` > > usage: > > ```swift > let x = something ?? Fatal("some errorMessage here") > > ``` I thought about this too with something like `panic()` but this requires more logging of where the line crash happened (and others like calling func etc). otherwise the crashing line logged will always show up as where fatalError was called which wont be much help or be a sutable replacement for fatalError. ---
**Author:** ![Letan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/letan/32/4982_2.png) [@Letan](https://forums.swift.org/u/Letan)\ **Post date:** [July 1, 2018, 5:42pm UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/47 "2018-07-01T17:42:43Z")
Without giving an opinion on the inclusion of the proposal. I will say if this were to be included it should incorporate the call context future direction as part of the proposal. Because if the motivation of this proposal is to improve debugging not having context would be a regression over a trap and a comment. This would be especially true in a non-IDE environment where the program output is not sufficient and debugging tools are not easily accessible. ---
**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\ **Post date:** [July 1, 2018, 7:38pm UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/48 "2018-07-01T19:38:39Z")
> [@masters3d](#): > > I thought about this too with something like `panic()` but this requires more logging of where the line crash happened (and others like calling func etc). otherwise the crashing line logged will always show up as where fatalError was called which wont be much help or be a sutable replacement for fatalError. Introducing the `Never`-rhs variant of `!!` allows you to: - Retain unsafe semantics with `!!` over `??`. Limiting the rhs to `Never` ensures that any non-nil value will always have a non-returning outcome. - Preserve the context information without extra compiler work (`#file`, `#function`, `#line`) - Allow the rhs use of the universal-error scenarios discussed in this thread and proposal: [Introducing Namespacing for Common Swift Error Scenarios - #22 by davedelong](https://forums.swift.org/t/introducing-namespacing-for-common-swift-error-scenarios/10773/22), also allowing the rhs extension to instances of the `FatalReason`, which has been designed for expansion to specific use scenarios: ```swift wrappedURL !! fatalError(reason: .unconstructableURL) ``` ---
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [July 1, 2018, 7:55pm UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/49 "2018-07-01T19:55:30Z")
I'm not trying to push my reasoning against the inclusion of the `!!` operator, everything I had to say about it has been said already by others and myself in this thread. There is still one thing that makes me wonder. Why is the new operator does not look like this `?!` ? When I created the custom [unwrap or trap](https://gist.github.com/DevAndArtist/dad641ee833e60b02fd1db2dbb488c6a) operator (two years ago) I used `?!` since it signals that the lhs is an optional while the rhs is `Never`. The `??` operator has already two overloads where rhs is non-optional or optional. The proposed `!!` operator does not force unwrap the lhs in that same same like `??` safely unwraps lhs. Operator symmetry does not add any symantical information but rather creates a new source of confusion. * * * The only use-case I had for this operator was to provide a little tedious to generate but rather safely looking API when working with interface builder outlets. ---
**Author:** ![Rod\_Brown](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/rod_brown/32/425_2.png) [@Rod\_Brown](https://forums.swift.org/u/Rod_Brown)\ **Post date:** [July 1, 2018, 9:58pm UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/50 "2018-07-01T21:58:27Z")
> [@Joe\_Groff](#): > > - What is your evaluation of the proposal? Probably -0.5. I was initially pro the idea, but after considering, I think there is value in the idea that a force unwrap should generally be self-documenting already. Should more documentation be required, an in-line comment documenting why the assumption should be safe would probably be more appropriate than a word or two stating the reason which may not give much value. > [@Joe\_Groff](#): > > - Is the problem being addressed significant enough to warrant a change to Swift? On first glance, yes. But after consideration, I’m not sure it adds much value above the standard detail. > [@Joe\_Groff](#): > > - Does this proposal fit well with the feel and direction of Swift? If this added value, I’d say it’s the right operator and would fit. All the standard reasoning is valid except I don’t see it actually adding anything to everyday code, and the exception cases can be worked around with fatalError where the description is more in-depth > [@Joe\_Groff](#): > > - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? N/A > [@Joe\_Groff](#): > > - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? Quick reading of the thread. ---
**Author:** ![hlovatt](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hlovatt/32/3044_2.png) [@hlovatt](https://forums.swift.org/u/hlovatt)\ **Post date:** [July 1, 2018, 10:57pm UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/51 "2018-07-01T22:57:43Z")
If `Never` becomes the bottom type then `??` will as a side effect it will allow `x ?? fatalError(“...”)`. Therefore probably better to allow `??` to have a `() -> Never` rhs now and `!!` as a shortcut to `x ?? fatalError(“...”)`. My feeling is that we should embrace a possible future Swift rather than fight it. Also it will give some useful experience of a bottom type. PS This contradicts my earlier feeling that I didn’t care if it was spelled `??` or `!!`. ---
**Author:** ![yxckjhasdkjh](https://avatars.discourse-cdn.com/v4/letter/y/278dde/32.png) [@yxckjhasdkjh](https://forums.swift.org/u/yxckjhasdkjh)\ **Post date:** [July 1, 2018, 11:09pm UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/52 "2018-07-01T23:09:40Z")
> [@svanimpe](#): > > `let event = NSApp.currentEvent!` > > This code clearly states that there should be an event. If the unwrap does fail, it's clearly because there's no event (for some unknown reason). > > `let event = NSApp.currentEvent !! "Trying to get current event for right click, but there's no event"` > > How is this any better? Only the obvious is stated here, but there is no clue as to the reason why there's no event. IMHO, this is a strawman. Of course these kinds of messages are not helpful. But I believe the purpose of a fatalError should _not_ be describing the obvious, but provide additional reasoning for the assumption; i.e. much like good comments, it should describe the _why_ not the _what_. E.g. `let event = NSApp.currentEvent !! "current event should have been set in initializer"` (or whatever). I'll give a more specific example: I could build a struct like this: ```swift struct Sum { let operands: [Int] init(_ first: Int, _ second: Int, _ rest: [Int]) { self.operands = [first, second] + rest } } ``` My code doesn't allow me to initialise this struct with fewer than two operands. However, my compiler doesn't know this, so if I want to access the first operand of a sum I have to catch this, e.g. like this: ```swift guard let firstOperand = mySum.operands.first else { fatalError("sum should have at least 2 operands") } ``` which IMHO is much better diagnostics than just "mySum.operands.first was force unwrapped but was nil" (or whatever the exact output is). ---
**Author:** ![beccadax](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/beccadax/32/34217_2.png) [@beccadax](https://forums.swift.org/u/beccadax)\ **Post date:** [July 2, 2018, 4:24am UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/53 "2018-07-02T04:24:32Z")
> [@svanimpe](#): > > None of these use cases are able to convince me: > > `let event = NSApp.currentEvent!` > > This code clearly states that there should be an event. If the unwrap does fail, it's clearly because there's no event (for some unknown reason). > > `let event = NSApp.currentEvent !! "Trying to get current event for right click, but there's no event"` > > How is this any better? Only the obvious is stated here, but there is no clue as to the reason why there's no event. > > `let existing = childViewControllers as! Array` > > This code clearly states that the `childViewControllers` should be `TableRowViewController` s. > > `let existing = childViewControllers as? Array !! "TableViewController must only have TableRowViewControllers as children"` > > Again, this only states the obvious, as do all the other examples in the proposal. If the examples were written like these instead: ```swift let event = NSApp.currentEvent !! "rightClick action should only be triggered by an event" ``` ```swift let existing = childViewControllers as? [TableRowViewController] !! "nib should contain only TableRow children" ``` Would you feel differently? Because if so, your objection is to the proposal, not to the feature. The fact that you can write a vacuous message string on an assertion doesn't—and shouldn't—stop us from putting message strings on assertions. (I also notice you didn't quote the examples where a value was interpolated into the message string, which are a bit stronger than these.) ---
**Author:** ![QuinceyMorris](https://avatars.discourse-cdn.com/v4/letter/q/d26b3c/32.png) [@QuinceyMorris](https://forums.swift.org/u/QuinceyMorris)\ **Post date:** [July 2, 2018, 7:31am UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/54 "2018-07-02T07:31:50Z")
When this was discussed previously, I thought it was the wrong solution to the right problem. I'm much more interested in a deeper solution to the problem of programmers letting optionals propagate in contexts where it would be more appropriate to handle them when they first appear. While this proposal does address that in part, I don't think it digs deep enough into the problem. However, digging deeper is a different discussion, so I don't want to head in that direction here. Part of me wants to reject the `!!` operator because it's really, really insubstantial. Functionally, it's identical to the `!` operator, just with a different message. In that sense, it doesn't fix anything. However, I think I'm going to give it a +1 after all, if somewhat hesitantly. That's because I've seen a lot of developer questions in the last few months where their app has crashed with the standard message ("Fatal error: Unexpectedly found nil while unwrapping an Optional value"). I've noticed that many developers have no idea what to do with this. They understand that their app will crash if "Swift tries to unwrap" a nil, but because it's a canned message, they don't quite understand that _they did it_. They tend to think it was something that was _done to them_. For that reason, and that reason alone, I suspect that it will help if the error message is one that the developer themself wrote. It changes the scenario from "it crashed" to "I crashed it", and I think that will help relatively inexperienced developers (inexperienced in Swift, I mean) grasp that the correct action is in their own hands. I'm not yet convinced about the revised fixit wording. I want to think about it a bit longer, while this debate (I'm sure) rages on for a while. ---
**Author:** ![svanimpe](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/svanimpe/32/38963_2.png) [@svanimpe](https://forums.swift.org/u/svanimpe)\ **Post date:** [July 2, 2018, 8:05am UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/55 "2018-07-02T08:05:37Z")
> [@yxckjhasdkjh](#): > > which IMHO is much better diagnostics than just "mySum.operands.first was force unwrapped but was ni Is it really that much better to warrant: 1. An additional operator in the language. 2. The use of `!! sum should have at least 2 operands` every single time you read from `operands` using `first`, `last`, ... ? I say no. If `operands.first!` crashes than that is obviously because it was `nil`, but shouldn't be. The error message "sum should have at least 2 operands" is of no help here, as it only states what you already know: that there should be an operand. It doesn't offer any hints as to the cause of the problem. In general, I don't think there are many cases where you could add a useful message. The only times when you can point at the cause of the problem in the error message is when the cause it obvious. But if it's obvious, then you don't need an error message ... ---
**Author:** ![svanimpe](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/svanimpe/32/38963_2.png) [@svanimpe](https://forums.swift.org/u/svanimpe)\ **Post date:** [July 2, 2018, 8:52am UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/56 "2018-07-02T08:52:53Z")
> [@beccadax](#): > > Would you feel differently? Because if so, your objection is to the proposal, not to the feature. The fact that you can write a vacuous message string on an assertion doesn't—and shouldn't—stop us from putting message strings on assertions. No 🙂 As explained above, I feel `!` should only be used when it is clear that a value is not `nil`. If it takes more than a few seconds for you to prove that, then the case is probably too complex for `!` and should use more explicit error handling. To give an example: The project I'm working on is currently at about 7.5K lines. There are 124 occurrences of `!` in this project. Of these 124 occurrences, most are related to initial setup and parsing static values (often in unit tests). I found only one that isn't 100% obvious. Here it is (somewhat simplified): ```swift guard form.isValid else { // amazing error handling } let date = form.date! ``` if `date!` fails to unwrap, I'm pretty sure you can guess where the bug is, even without a comment or `!!`? ---
**Author:** ![yxckjhasdkjh](https://avatars.discourse-cdn.com/v4/letter/y/278dde/32.png) [@yxckjhasdkjh](https://forums.swift.org/u/yxckjhasdkjh)\ **Post date:** [July 2, 2018, 8:57am UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/57 "2018-07-02T08:57:16Z")
> [@svanimpe](#): > > Is it really that much better to warrant: > > 1. An additional operator in the language. I'm impartial to this. the `??` + `Never` variant is good enough for me too. > [@](#): > > The use of !! sum should have at least 2 operands every single time you read from operands using first, last, ... ? If this access happens more often, this can really be encapsulated in a method on Sum, so this isn't a counter-argument IMHO. I do believe that the alternative error message is more helpful. This might not even be my code. Some other team member might have written this assertion. Later on, I might change the Sum initialiser so it allows for zero operands (for whatever reason). If I at some point get a crash with the specific error message, I know exactly what I did wrong. The "was nil but shouldn't be" could leave me scratching my head (as in "why did someone assume `first` could be unwrapped"?). And this was only an example off the top of my head. More importantly, the unwrapping could be happening much further away from the introduction of the `nil`, then just looking at the force unwrap wouldn't be very helpful. ---
**Author:** ![Pampel](https://avatars.discourse-cdn.com/v4/letter/p/3da27b/32.png) [@Pampel](https://forums.swift.org/u/Pampel)\ **Post date:** [July 2, 2018, 1:15pm UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/58 "2018-07-02T13:15:36Z")
+1 on the proposal but I'm not sure about the syntax... ``` let thing = someThing !! "someThing should never be nil because..." ``` ...because the diagnostic message looks like a value when in actual fact it's a statement, one that will crash your program if executed, and could be misleading especially given it's superficial similarity to `||`, ternaries and the other existing coalescing/chaining operators. ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [July 2, 2018, 2:57pm UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/59 "2018-07-02T14:57:06Z")
> [@Joe\_Groff](#): > > - What is your evaluation of the proposal? > > - Is the problem being addressed significant enough to warrant a change to Swift? > > - Does this proposal fit well with the feel and direction of Swift? > > - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? > > - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? I shared my thoughts on the proposal in its earlier stages; the proposal remains substantially the same, and my thoughts therefore haven't changed much either. There's little that hasn't already been brought up again in the thread, but I'll review the proposal as succinctly as I can: * * * I am quite opposed to the feature as proposed. In earlier discussions, we discussed the idea of `() -> Never` being permitted on the right-hand side of `??` (which would be consistent with `Never` eventually being a true bottom type) with some amount of community approval, and I'm glad to see that it's brought up again here. But _this_ proposal rejects that well-received idea. What it proposes in its stead, a new operator spelled `!!`, has (in my opinion) several significant defects: First, as an operator, it adds to the burden of syntax that Swift users have to learn. In fact, since the intention is for this operator to become a **commonly** used facility, it would increase that burden for **new** users. A common critique of Swift, and not an undeserved one, is that it has a lot of syntax, and this feature would add to rather than subtract from that problem if adopted. > Coming from other languages, working with optionals can be pretty hard--adding more to the options for dealing with them makes the language less approachable rather than more. New users already have to contend with the question of when to use force-unwrapping rather than `if let` or optional chaining; with this feature, they'd also be faced with the question of when to use `!` rather than `!!`. The proposal envisions this as a matter of house style (more on that below), meaning that there's no one good answer for a new user. Second, there is no reason why someone who wishes to use this feature could not trivially write an extension for themselves; in fact, as the proposal mentions, people have done exactly that with satisfactory results. The proposal itself envisions `!!` as a ["positive house standards choice"](https://github.com/apple/swift-evolution/blob/master/proposals/0217-bangbang.md#on-forced-unwraps). Such choices related to house style, particularly when trivially implementable, more appropriately belong to the set of features that are implemented by the parties making that choice rather than those vended to all users of Swift. Third, it makes **implicit** what would be **explicit** in `expr ?? fatalError("Reason")`: namely, that what occurs in the case of a `nil` value is a runtime error. As others have pointed out, `!!` typographically resembles `||`, and the right-hand side looks like a plain string with no indication that there's a fatal error involved. After all, one critique of `!` is that it is too succinct a way to spell an operation that can trap; `!!` would displace such uses without addressing that critique. Fourth, the examples in the proposal text are demonstrably not useful and mostly entirely redundant, as @svanimpe points out. I brought up this critique during earlier phases of the proposal, and still the problem persists. Therefore, I cannot agree with @beccadax that the objection "is to the proposal, not to the feature." If, after months, the many authors of the proposal don't/can't/won't write a meaningful right-hand side to illustrate the proper use of the feature, how do we anticipate users to do so in their code? This is a problem **intrinsic to the proposed feature**. I'm not at all placated by the fact that @beccadax might be able to come up with one or two good examples. What the situation suggests to me is that **the most common** real-world uses will look like what is shown in the proposal: users will be told not to use `!` and they will instead pervasively decorate their code with error messages that recite what `!` means. In the aggregate, it will not improve Swift code in the wild; it will merely make Swift code more verbose to read. It appears that the proposal was not initially motivated by a problem at all, but by a desire to incorporate a particular syntax. Indeed, that's how the entire proposal is written: "Motivation: 'Unwrap or Die' has been widely adopted by the community." The reasons seem to have been included only to justify that choice after it was made. For reasons I give above, I do not believe that the operator presented here encourages more "thoughtful" coding than the alternative `?? fatalError()` syntax, and I see no evidence that it promotes any **useful** reasons to be given for runtime traps. I feel the proposal does **not** fit well with the feel and direction of Swift. I'm not aware of similar features elsewhere, although evidently others have made this a common extension. I participated in many phases of this proposal and have given this topic some in-depth thought. ---
**Author:** ![davedelong](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davedelong/32/38708_2.png) [@davedelong](https://forums.swift.org/u/davedelong)\ **Post date:** [July 2, 2018, 3:06pm UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/60 "2018-07-02T15:06:46Z")
> [@xwu](#): > > If, after months, the many authors of the proposal don't/can't/won't write a meaningful right-hand side to illustrate the proper use of the feature, how do we anticipate users to do so in their code? This is a fairly insulting and judgmental comment. Please reconsider before posting such comments again. This proposal hasn't been updated in months, because, frankly, none of us work for Apple. The amount of time we have sunk in to this proposal easily runs in to the tens of thousands of dollars, if we were to have billed for it. Additionally, we were all surprised when the proposal came up for review; none of us had any indication or warning or notice that such a thing was going to or did happen; we discovered it accidentally. If we had known, perhaps we might have taken the time to update it. In the future, do not assume that everyone has the same luxury of time to pour in to the forums and evolution process that you do. ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [July 2, 2018, 3:09pm UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/61 "2018-07-02T15:09:20Z")
> [@davedelong](#): > > This is a fairly insulting and judgmental comment. Please reconsider before posting such comments again. > > This proposal hasn't been updated in months, because, frankly, none of us work for Apple. The amount of time we have sunk in to this proposal easily runs in to the tens of thousands of dollars, if we were to have billed for it. Sorry--I meant no offense by it. Quite the opposite: I fully believe that the you and co-authors have spent lots of time and care in the proposal, as much as possible. And yet, the problem persists. Therefore, it must not be a problem with lack of effort or a reflection on the quality of your work on the proposal; instead, it's a point against the idea being proposed and **intrinsic to the feature**. ---
**Author:** ![davedelong](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davedelong/32/38708_2.png) [@davedelong](https://forums.swift.org/u/davedelong)\ **Post date:** [July 2, 2018, 3:10pm UTC](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/62 "2018-07-02T15:10:26Z")
> [@xwu](#): > > And yet, the problem persists. Therefore, it must not be a problem with lack of efforts or a reflection on the quality of your work Again, you're assuming that we have infinite time to devote to making sure every proposal we put up is updated every time we think about it. This is a false assumption. Please stop assuming your know the intimate details of our lives and why we do (or do not) update things. [Previous page](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107.md?page=2) [Next page](https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107.md?page=4)