Make convert(::Type{<:AbstractTriangular}, A::Diagonal) consistently preserve storage structure

[Sacha0]

convert(::Type{LowerTriangular}, A::Diagonal) and convert(::Type{UpperTriangular}, A::Diagonal) preserve Diagonal storage structure, respectively returning LowerTriangular{T,Diagonal{T}} and UpperTriangular{T,Diagonal{T}}. In contrast, convert(::Type{UnitLowerTriangular}, A::Diagonal) and convert(::Type{UnitUpperTriangular}) discard the Diagonal storage structure via a full call, respectively returning UnitLowerTriangular{T,Matrix{T}} and UnitUpperTriangular{T,Matrix{T}}.

This pull request makes the latter (Unit(Lower|Upper)Triangular) methods preserve the Diagonal storage structure, consistent with the former ((Lower|Upper)Triangular) methods. Best!

[tkelman]

add a test?

[Sacha0]

add a test?

Good call! Tests added. Thanks!

[kshyatt]

Are these tests a good candidate for @inferred?

[Sacha0]

Are these tests a good candidate for @inferred?

What makes a good candidate for @inferred? Apologies for my ignorance.

[kshyatt]

IIUC @inferred tests if the type you get back is the one the compiler expects - it's a good way to check type stability.

[Sacha0]

IIUC @inferred tests if the type you get back is the one the compiler expects - it's a good way to check type stability.

Apologies for not being clear. To rephrase the question, when is testing with @inferred particularly worthwhile (in contrast to instances where testing with @inferred is possible yet not done)? Instances of observed type instability? Thanks!

[Sacha0]

Superseded by #17723.