You are correct. My point was about the risk that the two use cases are conflated by the api developer, because they have identical effects (when / as long as) a single concrete type is involved.
When the api developer is wrong, we end up, after a few rounds of api evolution, with code such as below, where the privileged/special position of DefaultFlags has no meaning at all:
struct Box<F: Flags> {
// Symmetry breakage for DefaultFlags, which should
// be handled as OtherFlags and YetAnotherFlags below.
init(_ flags: F = DefaultFlags()) { ... }
}
extension Box where F == OtherFlags {
init() { self.init(OtherFlags()) }
}
extension Box where F == YetAnotherFlags {
init() { self.init(YetAnotherFlags()) }
}
I know that we should not negatively judge language changes because some people may misuse them. Yet the risk for confusion is high, here, and I think it is better if it is expressed in this pitch.