# Optional return **URL:** \ **Category:** 💡 Ideas\ **Created:** [January 16, 2025, 1:18pm UTC](https://es.discourse.group/t/optional-return/2280 "2025-01-16T13:18:20Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![akodat](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/akodat/32/2241_2.png) [@akodat](https://es.discourse.group/u/akodat)\ **Post date:** [January 16, 2025, 1:18pm UTC](https://es.discourse.group/t/optional-return/2280/1 "2025-01-16T13:18:20Z")
A common pattern for memoization is to check if a variable/property is undefined and, if not, return the value or, if so, calculate the value, and then assign/return it. The initial test is essentially the same as the tests that motivated optional chaining. But, why not extend optional chaining to return? Rather than: ```javascript if (this.#foo) return this.#foo; ``` we do ```javascript return this.#foo? ``` This seems like a very common pattern, couldn't possibly cause syntactic issues, since the ? would already be acceptable wherever this would be used (currently, always follwed by a chained property), and actually reads like what it means. I'm sure this must have been proposed before, but couldn't find it, so apologies in the likely case that this is a repeat. ---
**Author:** ![tabatkins](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/tabatkins/32/170_2.png) [@tabatkins](https://es.discourse.group/u/tabatkins)\ **Post date:** [January 16, 2025, 4:58pm UTC](https://es.discourse.group/t/optional-return/2280/2 "2025-01-16T16:58:03Z")
```js return this.#foo? foo : bar; ``` Today that parses as a `?:` conditional; with the new syntax ASI would trigger, turning it into an optional return followed by a labeled statement. ---
**Author:** ![ljharb](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/ljharb/32/8_2.png) [@ljharb](https://es.discourse.group/u/ljharb)\ **Post date:** [January 16, 2025, 5:14pm UTC](https://es.discourse.group/t/optional-return/2280/3 "2025-01-16T17:14:17Z")
Do you have evidence that this is a common pattern? Why is new syntax warranted to remove a few characters? What problem is this solving? ---
**Author:** ![aclaymore](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/aclaymore/32/501_2.png) [@aclaymore](https://es.discourse.group/u/aclaymore)\ **Post date:** [January 16, 2025, 7:08pm UTC](https://es.discourse.group/t/optional-return/2280/4 "2025-01-16T19:08:03Z")
`return?` seems more natural, instead of having to wait until the end of the statement to be told that we might not return. > **[Optional Return](https://forums.swift.org/t/optional-return/17089)** > > I don't know if this idea has surfaced before, but I've found myself doing this way too often: func foo(\_ value: Int?) -\> Int { if let value = value { return value } // Do something else... } I wonder, if this syntax sugar... ---
**Author:** ![akodat](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/akodat/32/2241_2.png) [@akodat](https://es.discourse.group/u/akodat)\ **Post date:** [January 17, 2025, 2:21am UTC](https://es.discourse.group/t/optional-return/2280/5 "2025-01-17T02:21:33Z")
Yup, fair enough point. That does make the proposed syntax non-viable as it essentially means one must end the proposed option return with a semicolon: ```javascript return this.#foo?; ``` which, of course, isn't true for any other syntactic elements, AFAIK (best practices are to end every statement with a semicolon but that's irrelevant, of course). Plus the ?; doesn't look that nice, anyway. I guess the return? that aclaymore suggested might be more syntactically viable but that seems like a more significant change to the language (I had wrongly viewed my proposal as just a minor tweak to optional chanining). Almost certainly not worth the minor benefit. ---
**Author:** ![akodat](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/akodat/32/2241_2.png) [@akodat](https://es.discourse.group/u/akodat)\ **Post date:** [January 17, 2025, 2:30am UTC](https://es.discourse.group/t/optional-return/2280/6 "2025-01-17T02:30:03Z")
I haven't done a lot of research on how common this pattern is elsewhere. I seem to hit it a lot, myself, and I guess I figured that if it were common there'd be a groundswell of support for the proposal. ;-) Maybe that's a bad way to use this discussion group? If so, sorry. It seemed to be a convenience in the spirit of optional chaining though, admittedly, less common. In any case, Tab Atkins-Bittner pointed out a fatal flaw in the proposed syntax so not worth pursuing this any further. ---
**Author:** ![bergus](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/bergus/32/152_2.png) [@bergus](https://es.discourse.group/u/bergus)\ **Post date:** [January 18, 2025, 5:19am UTC](https://es.discourse.group/t/optional-return/2280/7 "2025-01-18T05:19:51Z")
> [@akodat](#): > > A common pattern for memoization is to check if a variable/property is undefined and, if not, return the value or, if so, calculate the value, and then assign/return it. There is already syntax support for this whole mechanism, not just the first bit that checks for and optionally `return`s a value: ```js return this.#foo ??= calculateFoo(); ``` You don't actually want to _optionally_ return, you will return `this.#foo` in all cases.