[Discussion] `qr(::AbstractArray, ::Tuple, ::Tuple, ::Tuple)` is a large source of ambiguities and type piracy

[lkdvos]

The current usage of LinearAlgebra.qr which specifies the labels is somewhat of a large source of method ambiguities and technically type piracy.
The problem is that most structured arrays specialize this method by qr(::StructuredMatrix, args...), which clashes with the current desired specialization pattern that wants to use the args... to dispatch.

From what I understood, this is mostly to be used with in the "named dimensions" context, where the tuples specify labels for the different tensor indices.

There are several possible solutions with advantages and disadvantages:

• specialize a::AbstractArray to become nameddims(a, labelsa)::NamedDimsArray, which now no longer clashes
• use dedicated types for the labels ::Tuple (this would fix the piracy, but not the ambiguity problems, unless the dedicated types are fully concrete I think)
• introduce a separate qr function that handles "tensor qr" as opposed to "matrix qr", which wraps LinearAlgebra.qr. Something like tqr(a::AbstractArray, la::Tuple, lq::Tuple, lr::Tuple) might work.

There is definitely a point to be made that LinearAlgebra.qr somehow means matrix qr decomposition, and pushing tensor algebra into that same function might be more than just extending a method to new types, but really also extending functionality. On the other hand, it is also quite convenient to just be able to use qr, and not think about whether or not this is a tensor or not.

[mtfishman]

Defining it as a new function TensorAlgeba.qr could be another option (related to your suggestion of creating a new function name).