And my point was/is that explicitly exposing associated (aka those implementing sub-) types is an anti-pattern, because it is not generally composable because explicit types are hard-coded cases whereas access via traits are extensible via orthogonal implementations.
Your factory method could return a trait and not the explicit type that implements the trait.
But the error (or challenges) in my conceptualization is at least that a trait doesn't inform the compiler the data size of its implementing type nor which other traits its implementing type implements.
Well the data size problem can be resolved by never storing objects unboxed on the stack nor unboxed in data structures. This has a performance cost of course.
The early binding to a specific trait could be solved by parametrizing the trait on the types of traits desired but then we need first-class intersections (aka conjunctions), e.g.:
trait Collection<T> {
fn iter() -> Iterator & T;
}
See I am advocating a design which inverts the control of typing for maximum composability (a complete solution to Wadler's fundamental Expression Problem). This is a design I was advocating for Scala 3. I am now starting to think I have to create my own language, because there isn't anything that will do this. Ceylon has first-class conjunctions and disjunctions, but they chose the anti-pattern of subclassing instead of ad hoc polymorphism. Perhaps I could have gotten Gavin King's ear a couple of years ago, but my conceptualization wasn't yet fully formed.
I'd really love if someone had already created the language I want. I was thinking Rust might be it, but I can start to acknowledge now that the focus is more on low-level compromises (for low-level optimization) to the potential high-level leap forward I am conceptualizing (for high-level optimization).
Please do correct me or point out other perspectives. I like feedback on this idea.
Edit: appears my idea is an alternative to early binding with type families.