.init<Subject: CustomStringConvertible>(xxx instance: Subject) vs. .init(xxx instance: CustomStringConvertible)

So just now learned of @_disfavoredOverload which solve the problem:

extension String {
    init<T: P>(xxx t: T) { fatalError("C") }
    @_disfavoredOverload
    init(xxx p: P) { fatalError("D") }
}

String(xxx: S())              // now calls "C"
String(xxx: S() as P)      // now calls "D"

So back to my original wondering, String now has these four init's:

init<Subject>(describing instance: Subject) where Subject : TextOutputStreamable
init<Subject>(describing instance: Subject) where Subject : CustomStringConvertible
init<Subject>(describing instance: Subject) where Subject : CustomStringConvertible, Subject : TextOutputStreamable
@_disfavoredOverload          // need this to favor the "existential" overload proposed below
init<Subject>(describing instance: Subject)

the first three are fast but only called with exact generic type match, when call with "existential" (is this the correct term?), the last one is called which is slow because it use reflection inside.
I think they should add these three overloads for efficiency to avoid calling the last generic version when called with "existential":

@_disfavoredOverload
init(describing instance: TextOutputStreamable) { ... }
@_disfavoredOverload
init(describing instance: CustomStringConvertible) { ... }
@_disfavoredOverload
init(describing instance: CustomStringConvertible  & TextOutputStreamable) { ... }