# \[Pitch\] Result builder scoped unqualified lookup

**URL:** <https://forums.swift.org/t/pitch-result-builder-scoped-unqualified-lookup/62190>\
**Category:** Pitches\
**Tags:** result-builder\
**Created:** [December 22, 2022, 8:00pm UTC](https://forums.swift.org/t/pitch-result-builder-scoped-unqualified-lookup/62190 "2022-12-22T20:00:06Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![Jumhyn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jumhyn/32/3891_2.png) [@Jumhyn](https://forums.swift.org/u/Jumhyn)\
**Post date:** [December 24, 2022, 2:47am UTC](https://forums.swift.org/t/pitch-result-builder-scoped-unqualified-lookup/62190/11 "2022-12-24T02:47:10Z")

</div>

I agree the current behavior and workaround here are not ideal. It really is a shame implicit member syntax doesn't work in this position. 🙁

I'm thinking about this pitch with regards to Doug's [post](https://forums.swift.org/t/se-0380-if-and-switch-expressions/61899/90) from the `if`/`switch` expressions review about replacing the magic of result builders with more general source-generation features:

> [@SE-0380: \`if\` and \`switch\` expressions](https://forums.swift.org/t/se-0380-if-and-switch-expressions/61899/90):
>
> For example, can we write a macro that does a result-builder transform on a closure? Or a macro that implements string interpolation by creating an instance of the `ExpressibleByStringInterpolation` type and forming `appendInterpolation` calls?
> 
> Right now, you can _almost_ do these things, but not completely. If we were to get to the point where we can do them completely, then the overall language (and its implementation) can get simpler, because these features truly do become syntactic sugar. Additionally, it means users can define similarly-powerful sugar through the macro system, so the language can stay simpler.

On its face, it seems like this would dig us deeper down the hole of 'magic' for supporting an ergonomic experience for result builders, and its not immediately clear how we'd dig ourselves back out if we wanted to achieve the goal of making result builders be 'just' a macro feature.

So I have a couple different thoughts on the pitch as-is:

- Are there existing language language features that we could improve to work around the issues presented here? Implicit member syntax _almost_ works, is there any way we could tweak parsing rules to get it fully working, or not?
- If not, is there a more general language feature looming behind this extension of result builders? This feels very similar to how Kotlin lets you rebind `this` within a closure scope so that lookup can find names outside the strict lexical context. We don't necessarily need to make that part of this pitch, but it would be nice to know that we're not introducing a feature just for result builders that will make it significantly more difficult to generalize them later.

---

_[View the full topic](https://forums.swift.org/t/pitch-result-builder-scoped-unqualified-lookup/62190)._