New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Replaced] Introducing the Unwrap-or-Die Operator (please see new PR) #729

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
9 participants
@erica
Collaborator

erica commented Jul 3, 2017

This proposal introduces an annotated forced unwrapping operator to the Swift standard library, completing the ?, ??, and ! family with !!. The "unwrap or die" operator provides text feedback on failed unwraps to support defensive programming. This operator is commonly implemented in the larger Swift Community and should be considered for official adoption.

See: [Pitch] Introducing the "Unwrap or Die" operator to the standard library

@ingconti

This comment has been minimized.

Show comment
Hide comment
@ingconti

ingconti Jul 3, 2017

It seems a useful proposal for defensive programming.

ingconti commented Jul 3, 2017

It seems a useful proposal for defensive programming.

@mRs-

This comment has been minimized.

Show comment
Hide comment
@mRs-

mRs- Jul 4, 2017

It seems a bit inconsistent to the ?? operator. The ?? Operator is the fall thru and always the same type as the left value. The !! operator would break this pattern. Especially if I am new to the language this would lead to massive understanding problems in my opinion.

mRs- commented Jul 4, 2017

It seems a bit inconsistent to the ?? operator. The ?? Operator is the fall thru and always the same type as the left value. The !! operator would break this pattern. Especially if I am new to the language this would lead to massive understanding problems in my opinion.

@regexident

This comment has been minimized.

Show comment
Hide comment
@regexident

regexident Jul 4, 2017

Regardless of concerns regarding beginner-friendliness I would greatly appreciate Swift to gain an expressive and self-documenting alternative to horrible !. Overall, I think having an expressive unwrap operator/function would help beginners to learn to write maintainable code in Swift.

Rust has had Option.expect(self, msg: &str) for ages and use of Option.unwrap() is generally considered a serious code-smell, having lead to a dedicated lint for it, even.

Promoting an unsafe and all too often misused escape-hatch by adding syntactic sugar for it was a very bad idea, imho. As such I'd go a step further and add an optional(?) compiler warning for use of ! (vs. !!) with accompanying fix-it in future, akin to Rust's lint.

regexident commented Jul 4, 2017

Regardless of concerns regarding beginner-friendliness I would greatly appreciate Swift to gain an expressive and self-documenting alternative to horrible !. Overall, I think having an expressive unwrap operator/function would help beginners to learn to write maintainable code in Swift.

Rust has had Option.expect(self, msg: &str) for ages and use of Option.unwrap() is generally considered a serious code-smell, having lead to a dedicated lint for it, even.

Promoting an unsafe and all too often misused escape-hatch by adding syntactic sugar for it was a very bad idea, imho. As such I'd go a step further and add an optional(?) compiler warning for use of ! (vs. !!) with accompanying fix-it in future, akin to Rust's lint.

@ingconti

This comment has been minimized.

Show comment
Hide comment
@ingconti

ingconti Jul 4, 2017

ingconti commented Jul 4, 2017

@regexident

This comment has been minimized.

Show comment
Hide comment
@regexident

regexident Jul 4, 2017

@ingconti

Just as null has been in programming for decades. Doesn't change the fact that it was a bad idea.

! and !! both have the same semantics. It's the self-documenting nature of the latter that matters. (I'm not advocating adding func expect(_ message: String) -> Wrapped to Optional, that's what !! is for.)

Verbosity is a feature when it comes to unsafe code. !! "can never be nil, because…" forces you to think about why this particular Optional should be considered safe to unwrap, ! doesn't. That's bad. And to add insult to injury ! was made easy to type, even. Syntactic salt should have been applied here instead (as would !! "…"), imho.

As with everything, there will be people simply doing !! "" if ! triggered a warning (and if one had a warning for that, too, they'd just do !! "…", and so on). But if you're actively and consciously avoiding safety, then it's only you to blame when things break. You can lead a horse to water but you can't make it drink

regexident commented Jul 4, 2017

@ingconti

Just as null has been in programming for decades. Doesn't change the fact that it was a bad idea.

! and !! both have the same semantics. It's the self-documenting nature of the latter that matters. (I'm not advocating adding func expect(_ message: String) -> Wrapped to Optional, that's what !! is for.)

Verbosity is a feature when it comes to unsafe code. !! "can never be nil, because…" forces you to think about why this particular Optional should be considered safe to unwrap, ! doesn't. That's bad. And to add insult to injury ! was made easy to type, even. Syntactic salt should have been applied here instead (as would !! "…"), imho.

As with everything, there will be people simply doing !! "" if ! triggered a warning (and if one had a warning for that, too, they'd just do !! "…", and so on). But if you're actively and consciously avoiding safety, then it's only you to blame when things break. You can lead a horse to water but you can't make it drink

@lattner

This comment has been minimized.

Show comment
Hide comment
@lattner

lattner Jul 5, 2017

Collaborator

FYI, the &&, ||, ?? operators are all short circuiting, this one is not. It's also unclear to me that we'd want to "encourage" force unwraps by making failures more "useful". It is also unclear if it is important enough to add another operator. Both points are super subjective though.

Collaborator

lattner commented Jul 5, 2017

FYI, the &&, ||, ?? operators are all short circuiting, this one is not. It's also unclear to me that we'd want to "encourage" force unwraps by making failures more "useful". It is also unclear if it is important enough to add another operator. Both points are super subjective though.

@erica

This comment has been minimized.

Show comment
Hide comment
@erica

erica Jul 5, 2017

Collaborator

@lattner I wouldn't object to it short circuiting.

And I've found yet another good example of where this would be useful (see the bottom of http://ericasadun.com/2017/07/05/result-types/ ). This is one of those "we keep using the thing because Swift keeps dropping us into situations where the most succinct answer is the forced unwrap in order to maintain the overall readability and flow of the code"

Collaborator

erica commented Jul 5, 2017

@lattner I wouldn't object to it short circuiting.

And I've found yet another good example of where this would be useful (see the bottom of http://ericasadun.com/2017/07/05/result-types/ ). This is one of those "we keep using the thing because Swift keeps dropping us into situations where the most succinct answer is the forced unwrap in order to maintain the overall readability and flow of the code"

@regexident

This comment has been minimized.

Show comment
Hide comment
@regexident

regexident Jul 5, 2017

"[…] It's also unclear to me that we'd want to "encourage" force unwraps by making failures more "useful". […]" – @lattner

To me it's not about making failures more useful but about enforcing (or at least encouraging) documentation for them. Yes, you could write comments today. But we all know comment-rot all too well. Thus let's have the compiler help us by at least making sure it stays attached to ! (or rather !!).

Those who chose to use T! out of laziness probably do so to not have to bother about error handling or by not knowing any better (and because ! is just so convenient to type and ignore the actual issue at hand). I doubt that "usefulness" of a failure is even remotely considered in such a situation.

If you however instead were warned about ! and urged to use !! instead then chances are much higher that by pondering about what to put into that error message you end up realizing that what you thought was "safe-enough" actually isn't safe at all.

Especially with SE-0054 ("Abolish ImplicitlyUnwrappedOptional type") having landed in Swift 3 there now are quite a bunch of additional scenarios for supposedly safe unwraps:

let foo: Int! = 42
// … here be some more code in between …
print(foo + 1) // Compiles.
	
let foo: Int! = 42
// … here be some more code in between …
let bar = foo
print(bar + 1) // Fails due to SE-0054

let foo: Int! = 42
// … here be some more code in between …
let bar = foo! // Why is this safe, again?
print(bar + 1) // Compiles.

let foo: Int! = 42
// … here be some more code in between …
let bar = foo !! "Should be fine as it's actually a T! 🤷‍♂️" // Ah, somewhat better!
print(bar + 1) // Compiles.

regexident commented Jul 5, 2017

"[…] It's also unclear to me that we'd want to "encourage" force unwraps by making failures more "useful". […]" – @lattner

To me it's not about making failures more useful but about enforcing (or at least encouraging) documentation for them. Yes, you could write comments today. But we all know comment-rot all too well. Thus let's have the compiler help us by at least making sure it stays attached to ! (or rather !!).

Those who chose to use T! out of laziness probably do so to not have to bother about error handling or by not knowing any better (and because ! is just so convenient to type and ignore the actual issue at hand). I doubt that "usefulness" of a failure is even remotely considered in such a situation.

If you however instead were warned about ! and urged to use !! instead then chances are much higher that by pondering about what to put into that error message you end up realizing that what you thought was "safe-enough" actually isn't safe at all.

Especially with SE-0054 ("Abolish ImplicitlyUnwrappedOptional type") having landed in Swift 3 there now are quite a bunch of additional scenarios for supposedly safe unwraps:

let foo: Int! = 42
// … here be some more code in between …
print(foo + 1) // Compiles.
	
let foo: Int! = 42
// … here be some more code in between …
let bar = foo
print(bar + 1) // Fails due to SE-0054

let foo: Int! = 42
// … here be some more code in between …
let bar = foo! // Why is this safe, again?
print(bar + 1) // Compiles.

let foo: Int! = 42
// … here be some more code in between …
let bar = foo !! "Should be fine as it's actually a T! 🤷‍♂️" // Ah, somewhat better!
print(bar + 1) // Compiles.
@lattner

This comment has been minimized.

Show comment
Hide comment
@lattner

lattner Jul 5, 2017

Collaborator

I see what you're saying, I still think it is going to be a highly subjective discussion :-)

Collaborator

lattner commented Jul 5, 2017

I see what you're saying, I still think it is going to be a highly subjective discussion :-)

@erica

This comment has been minimized.

Show comment
Hide comment
@erica

erica Jul 5, 2017

Collaborator

@lattner Many new developers put in ! because Xcode encourages them to do exactly that through fixits. They repeat and repeat until it compiles. Then stuff breaks for obvious reasons.

I think both new learners as well as experienced developers will benefit from a more descriptive operator. The new ones because Xcode will use that instead as the default "make this compile" and because maybe The Swift Programming Language will state "never use ! unless you know it will unwrap safely. If you know at that point in code that the unwrap cannot fail, prefer the !! operator. If you do not know whether the unwrap is safe, use conditional binding with guard or if". The experienced ones because it documents an audited reason that the unwrap is a positive and not a reactive decision.

Collaborator

erica commented Jul 5, 2017

@lattner Many new developers put in ! because Xcode encourages them to do exactly that through fixits. They repeat and repeat until it compiles. Then stuff breaks for obvious reasons.

I think both new learners as well as experienced developers will benefit from a more descriptive operator. The new ones because Xcode will use that instead as the default "make this compile" and because maybe The Swift Programming Language will state "never use ! unless you know it will unwrap safely. If you know at that point in code that the unwrap cannot fail, prefer the !! operator. If you do not know whether the unwrap is safe, use conditional binding with guard or if". The experienced ones because it documents an audited reason that the unwrap is a positive and not a reactive decision.

@ingconti

This comment has been minimized.

Show comment
Hide comment
@ingconti

ingconti Jul 6, 2017

ingconti commented Jul 6, 2017

@alistra

This comment has been minimized.

Show comment
Hide comment
@alistra

alistra Jul 8, 2017

I'm not a fan of this proposal.

I already think that T!, property!, unowned and as! should be deprecated to an alternative that is longer to write and the word unsafe or fatal in the name. The language constructs tend to be used by novice programmers, as they solve the problem and circumvent you having to use proper Optional management, but have the side-effect of sometimes crashing the program. They are also often used in example code of libraries on GitHub and novice programmers copy the code to their codebases.

I may be biased from client programming, but you never want your program to crash under the user, it is much better to just not do something instead. I understand that when writing backend code you may want the program to crash as soon as possible when encountering a bug, so you can have the feedback ASAP, but I think it's not worth adding an additional crash operator the the language.

I think that using guard let with else { fatalError("Reason") } is perfectly good and readable to use.

I also think that adding the !! operator would make not doing proper optional management more acceptable. People would feel that using !! is good enough, as they verbosely explained why they think it won't crash, but there is no type system backing that up.

I believe that Swift programmers should get acknowledged with proper Optional management and don't keep using ! and potentially !!. ! should eventually be changed to something more verbose and scary to use (e.g. unsafe in the name).

alistra commented Jul 8, 2017

I'm not a fan of this proposal.

I already think that T!, property!, unowned and as! should be deprecated to an alternative that is longer to write and the word unsafe or fatal in the name. The language constructs tend to be used by novice programmers, as they solve the problem and circumvent you having to use proper Optional management, but have the side-effect of sometimes crashing the program. They are also often used in example code of libraries on GitHub and novice programmers copy the code to their codebases.

I may be biased from client programming, but you never want your program to crash under the user, it is much better to just not do something instead. I understand that when writing backend code you may want the program to crash as soon as possible when encountering a bug, so you can have the feedback ASAP, but I think it's not worth adding an additional crash operator the the language.

I think that using guard let with else { fatalError("Reason") } is perfectly good and readable to use.

I also think that adding the !! operator would make not doing proper optional management more acceptable. People would feel that using !! is good enough, as they verbosely explained why they think it won't crash, but there is no type system backing that up.

I believe that Swift programmers should get acknowledged with proper Optional management and don't keep using ! and potentially !!. ! should eventually be changed to something more verbose and scary to use (e.g. unsafe in the name).

@ingconti

This comment has been minimized.

Show comment
Hide comment
@ingconti

ingconti Jul 8, 2017

ingconti commented Jul 8, 2017

@regexident

This comment has been minimized.

Show comment
Hide comment
@regexident

regexident Jul 11, 2017

I already think that T!, property!, unowned and as! should be deprecated to an alternative that is longer to write and the word unsafe or fatal in the name.

Totally agree (as evident from my previous PR response).

I also think that adding the !! operator would make not doing proper optional management more acceptable. People would feel that using !! is good enough, as they verbosely explained why they think it won't crash, but there is no type system backing that up. […] I believe that Swift programmers should get acknowledged with proper Optional management and don't keep using ! and potentially !!. ! should eventually be changed to something more verbose and scary to use (e.g. unsafe in the name).

Again, agree 100%. But then again I don't see Swift ditching ! any time soon out of sheer fear of angering the masses who came from ObjC and are not yet willing to acknowledge that unsafe use of nullable types is a bad idea.

What I personally would like (as a migration path towards a !-free Swift) is an option (which should be ON by default) to turn use of ! into warnings on debug builds and errors on release builds. I would further more like to have App Store submissions required said option to be turned on.

With that in place ! and !! would then act (and be reduced to) as a way to quickly prototype some code without having to 100% nail the types just yet (especially for REPLs, etc).

regexident commented Jul 11, 2017

I already think that T!, property!, unowned and as! should be deprecated to an alternative that is longer to write and the word unsafe or fatal in the name.

Totally agree (as evident from my previous PR response).

I also think that adding the !! operator would make not doing proper optional management more acceptable. People would feel that using !! is good enough, as they verbosely explained why they think it won't crash, but there is no type system backing that up. […] I believe that Swift programmers should get acknowledged with proper Optional management and don't keep using ! and potentially !!. ! should eventually be changed to something more verbose and scary to use (e.g. unsafe in the name).

Again, agree 100%. But then again I don't see Swift ditching ! any time soon out of sheer fear of angering the masses who came from ObjC and are not yet willing to acknowledge that unsafe use of nullable types is a bad idea.

What I personally would like (as a migration path towards a !-free Swift) is an option (which should be ON by default) to turn use of ! into warnings on debug builds and errors on release builds. I would further more like to have App Store submissions required said option to be turned on.

With that in place ! and !! would then act (and be reduced to) as a way to quickly prototype some code without having to 100% nail the types just yet (especially for REPLs, etc).

@erica

This comment has been minimized.

Show comment
Hide comment
@erica

erica Jul 14, 2017

Collaborator

Please note further arguments in favor of !! in the SE thread here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170710/038089.html

Collaborator

erica commented Jul 14, 2017

Please note further arguments in favor of !! in the SE thread here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170710/038089.html

@ingconti

This comment has been minimized.

Show comment
Hide comment
@ingconti

ingconti Jul 14, 2017

ingconti commented Jul 14, 2017

@JJJensen

This comment has been minimized.

Show comment
Hide comment
@JJJensen

JJJensen Aug 8, 2017

Perhaps a compiler option to make ! throw an exception would be more useful. Preferably it would default to true.

Then if you use ! your function needs to support throws. That wouldn't be too bad for beginners. And perhaps acceptable for fix-its too?

You could even redefine ! to throw, and e.g. !! to die :)

JJJensen commented Aug 8, 2017

Perhaps a compiler option to make ! throw an exception would be more useful. Preferably it would default to true.

Then if you use ! your function needs to support throws. That wouldn't be too bad for beginners. And perhaps acceptable for fix-its too?

You could even redefine ! to throw, and e.g. !! to die :)

@kielgillard

This comment has been minimized.

Show comment
Hide comment
@kielgillard

kielgillard Aug 8, 2017

I'm not sure enough attention has been given to the common use cases for the force unwrap operator. In my experience, it seems to be most commonly used when you want to decouple the initialisation of a value from one or more of its properties, eg: initialising a view controller and its outlet or view-ish properties. Some way of expressing to the compiler the lifecycle of the properties and having it enforce appropriate access for some "lifecycle scope" would eliminate the need for writing some (probably) relevant explanations throughout the code base. Thoughts? I've only cringeworthy ideas about how one would express this to the compiler such that it can reason about and determine appropriateness of lifecycles across modules.

kielgillard commented Aug 8, 2017

I'm not sure enough attention has been given to the common use cases for the force unwrap operator. In my experience, it seems to be most commonly used when you want to decouple the initialisation of a value from one or more of its properties, eg: initialising a view controller and its outlet or view-ish properties. Some way of expressing to the compiler the lifecycle of the properties and having it enforce appropriate access for some "lifecycle scope" would eliminate the need for writing some (probably) relevant explanations throughout the code base. Thoughts? I've only cringeworthy ideas about how one would express this to the compiler such that it can reason about and determine appropriateness of lifecycles across modules.

@kielgillard

This comment has been minimized.

Show comment
Hide comment
@kielgillard

kielgillard Aug 8, 2017

I guess the point I'm trying to make is that a better informed compiler could fail to compile and provide a message then rather than generate fatal code. Eg: "build failure: attempting to access outlet before view is loaded"

kielgillard commented Aug 8, 2017

I guess the point I'm trying to make is that a better informed compiler could fail to compile and provide a message then rather than generate fatal code. Eg: "build failure: attempting to access outlet before view is loaded"

@erica

This comment has been minimized.

Show comment
Hide comment
@erica
Collaborator

erica commented Aug 9, 2017

@jantuitman

This comment has been minimized.

Show comment
Hide comment
@jantuitman

jantuitman Aug 9, 2017

How about a method called .guard on an optional. result.value.guard(reason: “never nil when result is not an error case”). I don’t feel the need for extra operators (and concepts) polluting the language while this could be perfectly done with a well named method.

jantuitman commented Aug 9, 2017

How about a method called .guard on an optional. result.value.guard(reason: “never nil when result is not an error case”). I don’t feel the need for extra operators (and concepts) polluting the language while this could be perfectly done with a well named method.

@lattner

This comment has been minimized.

Show comment
Hide comment
@lattner

lattner Aug 9, 2017

Collaborator

Before this comes up for review, I'd like for you to expand the writing. Some observations:

  • This is a purely additive "syntactic sugar" proposal.
  • It's unclear if it will be widely used. Many people have "house styles" that avoid force unwraps and other ! operations.
  • This adds a new binary operator that all Swift developers can now encounter in code. This is a super high bar because operators (unlike method names) are symbols, which require you to have them memorized to understand what they do. The bar for adding builtin operators is exceedingly high - as one example, we almost didn't add ??.

I'd appreciate it if you could provide stronger motivation in the proposal that justifies why the problem being solved is so important that it is worth making the language more complicated for everyone.

Finally, this only fixes the case of x!, but does not fix try! (and other similar ! operations), nor does it help the case of trapping array operations, etc. It isn't clear to me why x! is so much more important to cover than try!, and why this is worth making the language inconsistent for.

Collaborator

lattner commented Aug 9, 2017

Before this comes up for review, I'd like for you to expand the writing. Some observations:

  • This is a purely additive "syntactic sugar" proposal.
  • It's unclear if it will be widely used. Many people have "house styles" that avoid force unwraps and other ! operations.
  • This adds a new binary operator that all Swift developers can now encounter in code. This is a super high bar because operators (unlike method names) are symbols, which require you to have them memorized to understand what they do. The bar for adding builtin operators is exceedingly high - as one example, we almost didn't add ??.

I'd appreciate it if you could provide stronger motivation in the proposal that justifies why the problem being solved is so important that it is worth making the language more complicated for everyone.

Finally, this only fixes the case of x!, but does not fix try! (and other similar ! operations), nor does it help the case of trapping array operations, etc. It isn't clear to me why x! is so much more important to cover than try!, and why this is worth making the language inconsistent for.

@erica

This comment has been minimized.

Show comment
Hide comment
@erica

erica Aug 10, 2017

Collaborator

@lattner on it but don't expect to see update until next week. (Immediate family obligations, sorry)

Collaborator

erica commented Aug 10, 2017

@lattner on it but don't expect to see update until next week. (Immediate family obligations, sorry)

@lattner

This comment has been minimized.

Show comment
Hide comment
@lattner

lattner Aug 10, 2017

Collaborator

No rush, thank you!

Collaborator

lattner commented Aug 10, 2017

No rush, thank you!

@erica

This comment has been minimized.

Show comment
Hide comment
@erica

erica Aug 18, 2017

Collaborator

@lattner Car died, knee died, sorry about the delay. (Good news: School starts Monday)

Collaborator

erica commented Aug 18, 2017

@lattner Car died, knee died, sorry about the delay. (Good news: School starts Monday)

@erica

This comment has been minimized.

Show comment
Hide comment
@erica

erica Mar 16, 2018

Collaborator

Updated with all revisions

cc @lattner @airspeedswift

Collaborator

erica commented Mar 16, 2018

Updated with all revisions

cc @lattner @airspeedswift

@lattner

This comment has been minimized.

Show comment
Hide comment
@lattner

lattner Mar 17, 2018

Collaborator

Hi @erica, thank you for revising the proposal, I hope your knee is feeling better!

Here are my thoughts on the proposal, fwiw:

  • I don't find the "Fixit Problem" and "Moral Hazards" to be useful motivation for this proposal, and (as seen on the evolution discussions) it is super distracting. The reason is that we can (and should!) fix the fixit problem completely independently of this proposal to introduce (for example) "x ?? <# default #>" instead of "x!". Once that happens, this motivation goes away. I strongly suggest removing it.
  • I disagree that we would change the fixit to recommending 'x !! "rationale"' if this proposal is accepted. That rewrite is just as bad as x!, and we should instead change the compiler to produce ?? in the fixit, which is safer and leads naive users to the more likely to be correct safe default.
  • The runtime diagnostic part of this could be useful, but it isn't clear to me why we would spell this thing as an operator.
  • As I mentioned before, this is a half measure, because it doesn't solve the problem for the other trapping operations like try! and as!. Your example shows an as! sort of example by using as? inside the code, but I find that to be awkward and inelegant, not something someone is likely to use.
  • From a linguistic standpoint, IMO, this is not a binary operator in the traditional sense: it isn't combining the two values into an operation/result like every other binary operator does, and because it is not postfix, it can bind incorrectly depending on the precedence of the neighboring binary operators

Finally, IMO, purely subjectively, the entire point of the x! operator is to be concise, which is undermined by adding a failure message. If you're trying to unwrap something and don't care about this aspect of concision, then it is fine to use something more verbose and obvious - like an 'unwrapOrDie' function call. Such a call would not have the problems I describe above.

Collaborator

lattner commented Mar 17, 2018

Hi @erica, thank you for revising the proposal, I hope your knee is feeling better!

Here are my thoughts on the proposal, fwiw:

  • I don't find the "Fixit Problem" and "Moral Hazards" to be useful motivation for this proposal, and (as seen on the evolution discussions) it is super distracting. The reason is that we can (and should!) fix the fixit problem completely independently of this proposal to introduce (for example) "x ?? <# default #>" instead of "x!". Once that happens, this motivation goes away. I strongly suggest removing it.
  • I disagree that we would change the fixit to recommending 'x !! "rationale"' if this proposal is accepted. That rewrite is just as bad as x!, and we should instead change the compiler to produce ?? in the fixit, which is safer and leads naive users to the more likely to be correct safe default.
  • The runtime diagnostic part of this could be useful, but it isn't clear to me why we would spell this thing as an operator.
  • As I mentioned before, this is a half measure, because it doesn't solve the problem for the other trapping operations like try! and as!. Your example shows an as! sort of example by using as? inside the code, but I find that to be awkward and inelegant, not something someone is likely to use.
  • From a linguistic standpoint, IMO, this is not a binary operator in the traditional sense: it isn't combining the two values into an operation/result like every other binary operator does, and because it is not postfix, it can bind incorrectly depending on the precedence of the neighboring binary operators

Finally, IMO, purely subjectively, the entire point of the x! operator is to be concise, which is undermined by adding a failure message. If you're trying to unwrap something and don't care about this aspect of concision, then it is fine to use something more verbose and obvious - like an 'unwrapOrDie' function call. Such a call would not have the problems I describe above.

@erica

This comment has been minimized.

Show comment
Hide comment
@erica

erica Mar 21, 2018

Collaborator

Please note: this branch probably cannot be merged unless I fix up my repo as I messed up several things this past weekend. I don't want to do my normal delete/recreate repo until I absolutely have to because I want to preserve this discussion

Collaborator

erica commented Mar 21, 2018

Please note: this branch probably cannot be merged unless I fix up my repo as I messed up several things this past weekend. I don't want to do my normal delete/recreate repo until I absolutely have to because I want to preserve this discussion

@erica erica changed the title from Introducing the Unwrap-or-Die Operator to [Replaced] Introducing the Unwrap-or-Die Operator (please see new PR) Mar 21, 2018

@erica erica closed this Apr 3, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment