You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know it technically breaks the contract for Base.promote_typejoin but I think in practice in many cases it is an improvement and I do not see scenarios when it would be a problem (given the intended way strings are used - i.e. that in this case type information should be kind of "ignored" in practice and it is better to do the conversion rather than have container having abstract eltype - unless someone explicitly asks for such a container).
Unfortunately the docstring for promote_typejoin requires that it returns a type which is a parent of both input types (and I think map and broadcast rely on this). It's not even clear that it is supposed to be overridden by custom types and that it's technically possible to do that properly. See JuliaLang/julia#38241.
Though it could be useful to have map and broadcast in Base use a kind of promotion function that types could override when appropriate. I imagine they don't use promote_type because in some cases it can lead to loss of precision, but we could have a function which is only implemented when promotion is guaranteed not to lose anything (like here).
Following #4 I would propose that instead of:
we have:
I know it technically breaks the contract for
Base.promote_typejoin
but I think in practice in many cases it is an improvement and I do not see scenarios when it would be a problem (given the intended way strings are used - i.e. that in this case type information should be kind of "ignored" in practice and it is better to do the conversion rather than have container having abstract eltype - unless someone explicitly asks for such a container).CC @nalimilan @quinnj
The text was updated successfully, but these errors were encountered: