Basically, the story was I had a function similar to f(a::Complex) = a, and expected it to accept Int64 and return complex(a).
Then apparently I got bewildered and realized Int64<:Real, but not Int64<:Complex.
Then as a frequent Matlab user, who’s used to see complex function handles real inputs indifferently, I started wondering why this type relation was designed intentional in julia.
I also learnt from other sources subtype/supertype relation is akin to inheritance, rather than a mathematical field extension.
Complex is not a DataType. It is a UnionAll. A shorthand for Complex{T} where T, and making Real <: Complex{T} where T doesn’t make sense, because it leaves out the T.
On the other hand, something Real{T} <: Complex{T} might make sense, but Julia does not allow subtyping non-abstract (i.e. concrete) types, probably for very good reasons. So you’d have to create an AbstractComplex type, which is what Number is.
The actual implementation of Complex (being non-abstract) is really just a red herring to this question. Sure, you can’t subtype a non-abstract type, but if we really wanted to express the mathematical truth that the Reals are embedded in the Complex universe, we totally could have structured the type tree with an AbstractComplex supertype. The simple answer is that these type trees aren’t describing mathematical truths but rather they’re practical realizations that we find useful.