# Add nil-collapsing call expression **URL:** \ **Category:** Pitches\ **Created:** [July 20, 2018, 7:13pm UTC](https://forums.swift.org/t/add-nil-collapsing-call-expression/14634 "2018-07-20T19:13:04Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\ **Post date:** [July 20, 2018, 8:15pm UTC](https://forums.swift.org/t/add-nil-collapsing-call-expression/14634/4 "2018-07-20T20:15:48Z")
> [@dyl](#): > > Is `throw` currently at all likely to become an expression? This topic was discussed just last week by core team members: [Unwrap or Throw - Make the Safe Choice Easier - #3 by Joe\_Groff](https://forums.swift.org/t/unwrap-or-throw-make-the-safe-choice-easier/14453/3). This idiom appears nice on the surface, but it doesn't interact well with the use case where the function itself is throwing. The `try? myFunc(optionalArg ?? throw MyError())` idiom swallows errors thrown by `myFunc` _in addition_ to those thrown when a `nil` argument is encountered. Proper support requires a feature that is orthogonal to the error system, just like optional chaining is orthogonal. FWIW, the general structure underlying a solution to this problem is `Applicative`. Some programming languages include syntactic sugar called "idiom brackets" which addresses the use case for optionals, but also provides sugar for other `Applicative` types such as `Result`, `Future`, etc. I'm not sure exactly what this kind of syntactic sugar would look like in Swift but I would love to see it explored and added to the language someday. --- _[View the full topic](https://forums.swift.org/t/add-nil-collapsing-call-expression/14634)._