@jiahao @stevengj Any reason not to merge this?

This seems to me like the right thing to do.

Oh. I didn't run the string tests locally. I'll define transpose(s::String)=s.

lgtm

Very related: #6395
Defining transpose just for strings seems really arbitrary. To make this work, it looks like we will have to go through with the plan in #6395 to make conj and ctranspose fall back to the identity function for everything.

Or, I guess

transpose(x) = x
ctranspose(x) = conj(transpose(x))
conj(x) = x

I know it seems a bit sketch, but I think this is the way to go. Let's try it out and see what comes of it.

I'll do that for now, but defining methods for Any always feels dangerous. There are no transpose methods for AbstractMatrix so for new matrix types this would give the wrong result. Any is so wild so maybe something like Scalar<:Any with Number<:Scalar and String<:Scalar would make sense. Alternative names could be Element or Atom, but the name is not the important part here.

I have sometimes wondered if we should add Atom (above Symbol, Number, etc.) and Collection (above AbstractArray, Associative, ...) abstract types.

This is a bit sketch, but less so than making it work only for strings.

Okay. I have added line definitions to operators.jl.

I like Atom and Collection, but which does a String qualify as?

Yep, that's one reason I didn't add those types :) You don't necessarily want to be forced to classify everything that way.

I like this one.

lgtm too