I’m +1 for overall this feature, but I have some fears. In addition, I’m ±0 for new name but it’s better than old.
First one is build functions are not instance method, but @devedevong describe above so I don’t talk it.
Second is a way of declaration to use it. General functions and computed properties are no problem, however Inferring from protocol requirements and closures are declared only definitions, not usages side. User cannot notice using it or not by see code.
In the first place, Result builder does not affect the return value whether this feature is used or not. Though user should be able to decide whether use it or not. Inferring from protocol requirements should be limited IDE suggestion, and we should allow users to choose whether use or not in closure in some way. (However, there is no need to rush, as the latter is likely to involve no disruptive changes.)
Third one is, it’s merged recently, support for function builders on stored struct properties. I think this PR make easy using result builder in initializer (Please let me know if I'm wrong). However, I don't think it's a good idea to put information just for the initializer in the property's declaration section. I sometimes feel boring when write initializer, but it should solved with improvements of initializer. For example, with Shorthand init, we can write:
struct A<B> {
let b: () -> B
init(@BBuilder self.b) {}
}