RFC: print Array{T,1} as Vector{T} and Array{T,2} as Matrix{T}

[KristofferC]

Personally I find this clearer, especially when types are nested.

As an example

1-element Array{Union{X28004, Array{T,1} where T},1}:\n X(Any[X(1)])

vs

1-element Vector{Union{X28004, Vector{T} where T}}:\n X(Any[X(1)])

Some potential objections:

• How about the other array types, AbstractVector, DenseVector etc? Could also be special cased imo.
• Could potentially hide that Vector{T} is just another name for Array{T, 1}. - I feel this is something you learn pretty quickly and the convenience in printing makes up for the slight "pedagogical" issue.

[KristofferC]

Statistics fail the doctests. @nalimilan, I'm not sure it is feasible to have Statistics live outside this repo but still run the CI / doctests for it. Too much friction.

[tkf]

• How about the other array types, AbstractVector, DenseVector etc? Could also be special cased imo.

Can this be generalized to user-defined types? How about

@typealias MyVector{T} = MyArray{T,1}

for writing const = MyVector{T} = MyArray{T,1} and generating (a very safe implementation of) show(::IO, ::Type{<:MyVector})?

[nalimilan]

Statistics fail the doctests. @nalimilan, I'm not sure it is feasible to have Statistics live outside this repo but still run the CI / doctests for it. Too much friction.

Yes, I guess we can point people to (a stable variant of) https://julialang.github.io/Statistics.jl/dev/ instead.

[mbauman]

The pedagogical reservation is something I struggled with in #31149, too. To help alleviate it, I made sure the docs for StridedArray prominently pointed out that it's a Union. Looks like we already have that in the Vector and Matrix docstrings, but all these special type printings still feel pretty opaque to me as it becomes impossible to get the REPL to display the actual definition. What if we limited them (all) to specific IOContexts, special cased from summary and method tables?

[JeffBezanson]

Suggested change

	isarray = x.name === Array{TypeVar(:T), TypeVar(:N)}.name
	isarray = x.name === Array.body.body.name

[mbauman]

Triage was pretty much in favor — the two reservations were:

• It's gonna break a lot of doctests.
• It'd be nice to have an "escape hatch" to get the actual type printed out... somehow.

If we're going to break the doctests, it may be worth doing a more comprehensive solution all at once — searching the type's module for (potentially exported) names that define aliases and printing out the most specific ones. @vtjnash will try generalizing it in this manner, which will make it more useful and provide a bit more of a reward to packages.

[StefanKarpinski]

• It'd be nice to have an "escape hatch" to get the actual type printed out... somehow.

Perhaps an IOContext parameter that disables this?

[nalimilan]

Would :compact => true make sense for this?

[tkf]

Can we have something like

"""
    show_typealias(io::IO, T::Type)

Try printing type alias for `T`.
"""
show_typealias(::IO, ::Type) = nothing

function show(io::IO, @nospecialize(x::Type))
    if get(io, :typealias, true)
        alias = try
            sprint(show_typealias; context = io)
        catch err
            msg = sprint(context = IOContext(io, :typealias => false)) do buf
                println(buf, "ERROR: show_typealias(::IO, ::")
                show_type(buf, x)
                println(buf, ") failed")
                showerror(buf, err)
            end
            println(stderr, msg)
            ()
        end
        if !isempty(alias)
            print(io, alias)
            return
        end
    end
    show_type(io, x)
end

function show_type(io::IO, @nospecialize(x::Type))
    # current show(::IO, ::Type) implementation
end

? (It can be made safer and more efficient but I think it's enough for a sketch.)

[JeffBezanson]

I think we should merge this since (1) everyone seems to agree on this subset of changes, (2) we might as well get all those test and doc updates in.

[KristofferC]

The annoying part is that this breaks doctest for Statistics which is not in this repo :/ Not sure how to deal with it. Turn off the doctests for Statistics?

[KristofferC]

cc @nalimilan

[nalimilan]

Yeah I already commented above. If that's possible, turning off doctests for Statistics should be OK since we run them in Statistics.jl anyway. Otherwise the section the manual could point to https://julialang.github.io/Statistics.jl/dev/.

[vtjnash]

Yeah, I have the same problem over at #36107. I made the necessary changes locally just for testing. We could push those upstream, then merge this with the new commit hash. Or figure out how to stop running them. I'm inclined towards the former?

I think we should merge this since (1) everyone seems to agree on this subset of changes, (2) we might as well get all those test and doc updates in.

Pros: we think this subset is good, and it'd directly reduce the diff of future possible changes. Cons: if we're going to break a lot of doctests (with this, and then again with (#361007), might be worth doing it all at once, and not twice.

[KristofferC]

#36107