-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some concrete types are not properly interned #31696
Comments
Let me give a small recap of my thoughts on #25430, if I still remember correctly... The issue are types like these: julia> T1 = Tuple{Int8}
Tuple{Int8}
julia> T2 = Tuple{T} where T<:Int8
Tuple{T} where T<:Int8
julia> isconcretetype(T1)
true
julia> T1 === T2
false
julia> T1 == T2
true As noted, we have several places where we assume that if Alternatively, we could try to normalize types to equal concrete types (if possible) during construction, even if the respective concrete type has not been constructed/cached before. I'm doubtful, however, whether that can be achieved in general. |
Ah, #25796 almost fixes this, see #25796 (comment). |
FWIW, this also manifests in
|
Even uglier is this silent monstrosity 🤣 :
|
With #25796 merged, the observed ill effects here should all be remedied: the assumption that for concrete types, equally is identity is not trusted blindly anymore. However, it would still be desirable if that were true, as it would allow some fast-paths to kick in more often. So not sure if we should leave this open or consider it closed. |
I going to call it closed, though we'll keep working on edge cases as we can find them. |
Internally in the system, we rely on the fact that concrete types are comparable by pointers. However, it is possible to create type signatures that are
==
to concrete types, but are not normalized to the corresponding type, causing all sorts of problems. Example:The text was updated successfully, but these errors were encountered: