# Is there sugar-syntax for \`Result.failure\` propagation?

**URL:** <https://forums.swift.org/t/is-there-sugar-syntax-for-result-failure-propagation/57882>\
**Category:** Using Swift\
**Tags:** generics\
**Created:** [June 7, 2022, 2:49pm UTC](https://forums.swift.org/t/is-there-sugar-syntax-for-result-failure-propagation/57882 "2022-06-07T14:49:11Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![Jeehut](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jeehut/32/21743_2.png) [@Jeehut](https://forums.swift.org/u/Jeehut)\
**Post date:** [June 26, 2022, 6:24pm UTC](https://forums.swift.org/t/is-there-sugar-syntax-for-result-failure-propagation/57882/10 "2022-06-26T18:24:09Z")

</div>

@olavfosse I just wrote a pitch very much related to this thread, please see here:

> [@If/guard-let-catch for conveniently accessing both Result type cases](https://forums.swift.org/t/if-guard-let-catch-for-conveniently-accessing-both-result-type-cases/58492):
>
> Motivation A few weeks ago, I had [asked on Twitter](https://twitter.com/jeehut/status/1524056421494669312) if developers prefer error handling in Swift by using throws vs. returning Result. Of the 102 votes, 45% voted for "I prefer Result", which is 40% more than the 32% who voted for "I prefer throws" ([source](https://twitter.com/jeehut/status/1524056425076514817)). While this small survey isn't representative by any means, it still proves that there's clearly high interest in using Result for error handling (and not only for closure return types), even if that means we have to build nested error types…

---

_[View the full topic](https://forums.swift.org/t/is-there-sugar-syntax-for-result-failure-propagation/57882)._