Skip to content
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

invalid type application returns instead of throwing #54348

Open
nsajko opened this issue May 3, 2024 · 2 comments
Open

invalid type application returns instead of throwing #54348

nsajko opened this issue May 3, 2024 · 2 comments
Labels
domain:types and dispatch Types, subtyping and method dispatch kind:breaking This change will break code kind:minor change Marginal behavior change acceptable for a minor release

Comments

@nsajko
Copy link
Contributor

nsajko commented May 3, 2024

julia> struct S{A, B<:AbstractVector{A}} end

julia> S{<:Any,Matrix}  # expected to throw, as `Matrix` doesn't subtype `AbstractVector`
S{<:Any, Matrix}

julia> S{<:Any,Matrix} <: S  # a paradox?
false

If the parameter constraint in the definition of struct S is relaxed (!) like below, the type application throws as expected:

julia> struct S{A, B<:AbstractVector} end

julia> S{<:Any,Matrix}
ERROR: TypeError: in S, in B, expected B<:(AbstractVector), got Type{Matrix}
Stacktrace:
 [1] top-level scope
   @ REPL[2]:1

This perhaps suggests a fix: when Julia sees a parameter constraint with a type application, it could consider as multiple type constraints, e.g., <:AbstractVector{A} could be internally interpreted as two constraints, <:AbstractVector{A} and <:AbstractVector. If you get what I mean.

@nsajko nsajko added domain:types and dispatch Types, subtyping and method dispatch kind:correctness bug ⚠ Bugs that are likely to lead to incorrect results in user code without throwing labels May 3, 2024
@vtjnash vtjnash added kind:feature Indicates new feature / enhancement requests kind:breaking This change will break code kind:minor change Marginal behavior change acceptable for a minor release and removed kind:correctness bug ⚠ Bugs that are likely to lead to incorrect results in user code without throwing kind:feature Indicates new feature / enhancement requests labels May 3, 2024
@KristofferC
Copy link
Sponsor Member

Dup of #53380?

@vtjnash
Copy link
Sponsor Member

vtjnash commented May 3, 2024

We could, but you potentially lose the ability to specify some type constraints in dispatch, so it may not be worthwhile to add the error, as it doesn't cause any issues to be permitted

@JuliaLang JuliaLang deleted a comment from Tuhidsjfs May 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:types and dispatch Types, subtyping and method dispatch kind:breaking This change will break code kind:minor change Marginal behavior change acceptable for a minor release
Projects
None yet
Development

No branches or pull requests

3 participants