Promote different types to dynamic?

[jishnub]

julia> promote(static(0), static(1))
ERROR: promotion of types StaticInt{0} and StaticInt{1} failed to change any arguments

Perhaps these should return Ints?

[Tokazama]

It seems like the appropriate thing to do would be return (static(0), static(1)), just the same as promote(0, 1) returning (0, 1).

[jishnub]

Won't that defeat the idea of promoting to a common type?

[Tokazama]

The difference in type here is more of an implementation detail. If we could have StaticInt without the actual number stored as the type we would.

[Tokazama]

Perhaps we need a specialized promotion approach similar to Unitful.jl

[jishnub]

promote is expected to "Convert all arguments to a common type", and I find patterns such as the following useful:

julia> struct A{T}
       x :: T
       y :: T
       end

julia> A(x...) = A(promote(x...)...)
A

julia> A(1,1)
A{Int64}(1, 1)

julia> A(1.0,2)
A{Float64}(1.0, 2.0)

Would be nice to have this accept static arguments as well, even if the result isn't static.

[chriselrod]

I think we should generally respect the interfaces of methods like convert or promote.
Ideally, the language would be able to enforce interfaces more broadly -- and allow users to add rules for their own functions.
But Base.convert has at least started doing this:

julia> convert(StaticInt{4}, 2)
ERROR: TypeError: in typeassert, expected StaticInt{4}, got a value of type StaticInt{2}
Stacktrace:
 [1] convert(#unused#::Type{StaticInt{4}}, x::Int64)
   @ Base ./number.jl:7
 [2] top-level scope
   @ REPL[4]:1

And I'd be on board with Base.promote following suite.

[Tokazama]

I understand the logic behind using promote this way but I still don't think this is what the original intention behind promote was. It was to make it easier to pass mismatched types to things like +. I'm not sure what the benefit of this is besides occasionally avoiding errors when there is not a proper overload of a method for static types. In such cases it may end up causing unintended behavior for users that's harder to pinpoint the root cause.

I just want to make sure we aren't changing this behavior just for a quick fix