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

lower bound interferes with typevar value inference #30713

Closed
oxinabox opened this issue Jan 14, 2019 · 4 comments
Closed

lower bound interferes with typevar value inference #30713

oxinabox opened this issue Jan 14, 2019 · 4 comments
Labels
types and dispatch Types, subtyping and method dispatch

Comments

@oxinabox
Copy link
Contributor

Consider the following:

struct XX end
struct YY end

bar(a::A, b::B, c::C) where Tuple{A,B}<:C<:Union{Tuple{XX,YY}, Tuple{YY,XX}} where A where B = C

@show bar(XX(), YY(), (XX(),YY()))

gives:

julia> @show bar(XX(), YY(), (XX(),YY()))
ERROR: UndefVarError: C not defined
Stacktrace:
 [1] bar(::XX, ::YY, ::Tuple{XX,YY}) at ./REPL[3]:1

Expected is to return Tuple{XX,YY}

Similarly:

julia> @show bar(YY(), XX(), (YY(),XX()))
ERROR: UndefVarError: C not defined
Stacktrace:
 [1] bar(::YY, ::XX, ::Tuple{YY,XX}) at ./REPL[3]:1

Expected is to return Tuple{YY,XX}

For interest:
bar(XX(), YY(), (XX(), XX()) and bar(XX(), XX(), (XX(), XX()) , and bar(XX(), XX(), (YY(),YY())) and bar(YY(), YY(), (YY(),YY())) and bar(YY(),XX(), (YY(),YY())) give method errors

@charleskawczynski
Copy link
Contributor

Shouldn't the assignment be to something else (e.g., "xor") and not C

@JeffBezanson JeffBezanson changed the title Parametric typevar vanishes for complicated double bound lower bound interferes with typevar value inference Jan 14, 2019
@JeffBezanson JeffBezanson added the types and dispatch Types, subtyping and method dispatch label Jan 14, 2019
@JeffBezanson
Copy link
Member

Yes, I think the lower bound just makes it too hard for us to derive a unique value for C. It works without the lower bound.

@oxinabox
Copy link
Contributor Author

oxinabox commented Jan 14, 2019

It looks to me, based on the MethodErrors the dispatch is actually working,
it is just losing C somewhere.

@JeffBezanson
Copy link
Member

Yes, dispatch is now (as of 0.7) totally de-coupled from determining the values of static parameters. We know the arguments are a subtype, and so the method matches, we just don't know what value C should have. It's not losing the value; it is unable to determine a value for C in the first place.

There are various cases where we can't determine the value of a static parameter, and we decided it was better to give errors in those cases than to affect method matching --- that way (1) if you don't use the value of the static parameter there's no problem, (2) if you hit the error you can work around it with an @isdefined check, and (3) we can improve static parameter value inference without changing dispatch behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
types and dispatch Types, subtyping and method dispatch
Projects
None yet
Development

No branches or pull requests

4 participants