I would agree that “all concrete types are final” is poor wording and implies that it’s a leaf node on the subtyping tree, which is not true. My current mental model is that with the exception of Type{T} and unions thereof subtyping DataType, Unions making ad-hoc supertypes, and Union{} subtyping every type, we DO have a type tree with concrete leaf nodes and abstract nodes otherwise, and this is what most of the reflection methods will cover. Is that accurate, and if so would it be helpful?
I don’t know whether this is accurate, but it’s also my current mental model (and why it’s still fine for a lot of code in practice to think about a “type tree” in my opinion).
Following @nsajko’s suggestion I just made a PR to suggest a small addition to the manual page: Documentation: Add notes about subtypes of concrete types by angerpointnerd · Pull Request #58017 · JuliaLang/julia · GitHub
2 Likes
FYI: The PR linked directly above was merged!
It doesn’t include an explicit statement about the “tree-ness” of the type graphs in the absence of Type{T} and Union{}, mostly because as @nsajko demonstrated you can still interconnect individual branches using regular Unions.
But I hope it makes the point clearer that Type{T} and Union{} are (apparently the only) exceptions to "concrete types cannot have subtypes. The manual now hopefully provides more clarity for answering the original question of this topic (which I just now realized is almost exactly 5 years old already 
But evidently it was still a relevant question 
)
1 Like