[Pitch] Result builder scoped unqualified lookup

[AliSoftware (Olivier Halligon)]

@angela-laar

I think it's valuable that everything you can write inside of a result builder body that is context specific, be inside the result builder scope. Separating the namespace from the result builder scope introduces a level of indirection that adds complexity to both the transform and the developer experience of using the result builder.

@angela-laar What do you think of my suggestion above of using a parameter to the attribute… which we could consider adopting incrementally if it helps, while opening to all the possibilities

• @resultBuilder: current Swift behavior (thus avoiding source breaking changes)
• @resultBuilder(Self): the new behavior described in your pitch, where the declarations in the result builder type itself would be used to resolve unqualified lookup — excluding the buildXXX methods from that lookup though
• @resultBuilder(Foo) the new behavior but where nested type Foo is the one used for unqualified lookup, instead of the parent result builder type itself (Self). — Which is an option we could consider as a Future Direction for now if it helps.

---

In my mind I see a nice parallel to this with how one can use the projectedValue of a Property Wrapper:

• you can just not provide one (similarity with @resultBuilder without any type provided for unqualified lookup)
• if you provide one, it's very common from the value to be the property wrapper itself (var projectedValue: Self { self }, similarity with @resultBuilder(Self) proposed above)
• but if you want more control and flexibility about what to expose (and especially don't want to expose everything from your PW/RB as public API), you have the flexibility of using an arbitrary projected value (var projectedValue: Projection { … }, similarity with @resultBuilder(DSLPublicAPI))