I'm glad to see that there's an "considered alternative" section for Using reflection types in the init(attachedTo:) signature, but I hoping we don't have to give up on that just yet. Something about the non-uniformity of the various init overrides seems ... suboptimal to me. Especially because I imagine it'll be pretty common for people to want to introspect details of the "attachee" (do we have a name for this?), and the reflection types are a very natural way to communicate that.
For example, a web framework might want to do something like this:
// Redundant name.
// It would be nice if the name of the function could be accessed directly
@get(name: "index")
func index() -> HTTPResponse { ... }
We considered using types from the Reflection module to represent declarations which have reflection attributes. For example, Reflection’s
Fieldcould be used as the type of the first parameter ininit(attachedTo:)when a reflection attribute is attached to a property declaration.
IMO this seems like a useful case study that should influence the design of the reflection library. Perhaps it's useful to have a AnyField vs Field<T> distinction, like with AnyKeyPath/KeyPath<Root, Value>.