Make the behavior of promote_noncircular the default?

[timholy]

Before #19918 I used to see a lot more StackOverflowErrors in my own code. Should we consider adopting its behavior for the general promotion mechanism?

To be a little more concrete in my description than I was in #19918, note that we have this:

julia> ap, bp = promote('a', 2)
('a', 2)

i.e., promote does not guarantee that the types will change. So if you employ this common pattern:

foo{T}(x::T, y::T) = # "real" definition
foo(x, y) = foo(promote(x, y)...)  # the fallback definition

then foo('a', 2) will result in a StackOverflowError. Those errors sometimes take a long time to resolve (in complicated cases, I've seen tens of minutes) and the backtraces are not very helpful; it's particularly awful if you're ssh-ing over a slow link and you just watch the text scroll by...

One danger: what if there are genuine applications where you promote, and then test the two types to see if they are the same; if not, do something different. I can't remember seeing code like that, but it could exist in principle.

So alternatively perhaps we should make promote_noncircular an official exported interface, and cross-link the docstrings.

And finally, we could keep the status quo, or eliminate promote_noncircular entirely.

[JeffBezanson]

What this comes down to: should promote(x,y) give an error by default if x and y come out unchanged?

[StefanKarpinski]

promote vs trypromote – the former could error on no promotion vs the latter just leaving alone?

[JeffBezanson]

Do we have any examples of cases where we want the trypromote behavior? I can't find any in Base.

[JeffBezanson]

One case that seems useful is "make sure these have the same type", in which case it's ok if the arguments already have the same types. So maybe that should be allowed by promote as a special case.