I have always been bugged by the names Complex128 = Complex{Float64}, etc, as there is always (probably because I’m not a heavy user) a tiny mental step to divide the number to know the actual precision (64 bits for Complex128). I would find it clearer to have Complex64 meaning Complex{Float64}, so that the number indicates directly the float type used. Also, it seems more scalable: Quaternion256 starts to be unreadable, let alone Octonion512. My concern is also that it makes a precedent for naming things, like Point3d_192 = Point3d{Float64}; but imho, 192 carries much less interesting information (“192 bits are used in total”) than 64 (“coordinates are encoded as Float64”).
What do you think about deprecating those alias, and later on defining Complex64 = Complex{Float64}, etc ?
As far as I know, currently it is the case that all isbits types in Julia that have names indicating the number of bits have names indicating the actual number of bits. Complex{Float64} really is a 128 bit object. I think it would be confusing if some types had names indicating the actual number of bits, but other types had names indicating the number of bits of one of their fields.
I’m not aware of Base types having fields which are named after their number of bits, except for Complex; the basic integer and float types are primitive type and have no fields, so they are not fully on the same level as Complex. But if the proposal seems confusing, I would actually also be fine with only deprecating Complex128 etc. without adding later Complex64 = Complex{Float64}.
I’m mildly in favor of getting rid of these, if only because Complex128 is ambiguous, since any eltype with 64bit size (e.g. Int64) will give you a Complex type of size 128.
Historically, the Complex128 type actually preceded Complex{Float64} — it was originally a bits type because Julia didn’t have immutable types. (https://github.com/JuliaLang/julia/issues/13)
So, at this point, deprecating Complex128 makes a lot of sense.
complex128 and complex64 are also present in numpy. So there is some more history than just Julia for these primitives
Note that in NumPy they are a primitive type, for performance reasons, and the name reflects that. In Julia this is not the case, and the name is a historical artifact.
(However, I agree that using Complex32 for Complex{Float32} could add to the confusion. Better to drop the aliases entirely.)