cc @johnno1962

Hmm, seems reasonable. cc @rintaro should we allow this as a special-case?

@swift-ci create

Not sure how @Self should be handled for class es, but the Parser definitely should parse it as an attribute name.

I suppose for non-classes it would just be the type, but for classes it won’t be a valid name unless the class is final. WDYT?

I‘m not sure this is fully correct though, at least if we take a look at a function builder example in context of a class.

What if you have a base function builder which is a class and provides some static builder functions and the `build` function from above. Then a subclass provides more static builder functions.

@_functionbuilder
class Base {
  static func build<T>(@Self content: () -> T) -> T { content() }
  static func buildEither(first: ...) -> ...
  static func buildEither(second: ...) -> ...
}
// still non final
class Sub: Base {
  static func buildIf(...) -> ...
}

let builder: Base.Type = Sub.self
// I think build should still be able to use all builder functions from Base
// up to Sub even though at this point this is transparent
builder.build { ... }

I think Self in such context should remain dynamic.

cc @slavapestov