-
Notifications
You must be signed in to change notification settings - Fork 38
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
@match
gives the incorrect results when types are passed in as values
#189
Comments
It's because in the first example those are literal patterns because they are |
I see. So julia> one = 1; two = 2;
julia> x = two;
julia> @match x begin
one => "One!"
two => "Two!"
_ => "Many!"
end
"One!" Maybe an error could be thrown if two patterns are the "same" on the left side? |
That's like #127 |
So can we close this one? |
I'd close this but pin it as it is a FAQ. |
I would just include an appropriate error message? |
Do you have any design ideas? MLStyle can detect redundant patterns in some cases, but I'm not sure if I should mark things as intentional or unexpected. |
Is there any benefit to allowing redundant cases (#127)? |
Given the following result for matching on values
I'd expect the following to similarly match on values and output
"I'm a Type{Float64}!"
:Instead it outputs
"I'm a Type{Int}!"
. I now know that the recommended way of doing this isbut still the other version just silently gives the incorrect result and it can be pretty tricky to debug code that has this mistake in it. And it's still not really clear to me why the other version is wrong.
If it's not possible to get type-as-value version working, would it at least be possible to throw an error when a type is passed in as a value like this?
The text was updated successfully, but these errors were encountered: