Skip to content

New convert(::Type{String}, ...)::String methods shouldn't invalidate #56173

Open

Description

This is a concrete case of a more general problem. Consider a convert like this one in StringManipulation.jl

Right now that method invalidates a lot of code because the compiler already used information about convert(String, ...) calls at compile-time. Mostly, it knows that it returns ::String and that it can inline a few concrete cases, such as convert(::Type{String}, ::String) which is identity.

For example, the dispatch we union-split convert(::Type{String}, ::Any) to almost everywhere uses all this information:

if a isa String
    a
elseif # ...
else
    convert(String, ...)::String
end

The issue here is that the compiler failed to realize that its compile-time information is actually preserved by the new method!

The new method infers to ::String (and in this case has only has one concrete callable signature, so easy to infer eagerly) and it trivially has no intersection with any existing methods (since it's not type-piracy). So nothing about the validity of the existing code actually changed!

I'm brushing aside some important details like effects, etc. - but overall, this looks like a useless invalidation to me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions