-
-
Notifications
You must be signed in to change notification settings - Fork 409
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
Pattern Match claims case to be not matchable although it should be #2408
Comments
I found out why this might not work as expected: |
Next step for debugging would be to run in From that we could figure out what the issue is and how to proceed. |
The whole match expr has the following AST:
The types of the first case and the match expression are indeed identical. When determining if the pattern can match, it is failing when comparing the following
which is the result of
This comparison basically tells me that |
@sylvanc said he could get it to compile if he did two things:
On the sync call we determined that it was stopping at We're keeping the label on so we can discuss this on next week's sync, because we ran out of time. |
I am really sorry to have missed the Sync call, I really liked following along your thinking and digging. To make things clear, the above code sample and the type definition are not wrong because While the actual issue was worked around long ago and the fixes mentioned by @sylcanc are fixing the code sample above, the remaining problem is the bad error report. I am trying to find a proper backtrace and the actual flaw in the |
The comparison that fails and leads to the match being rejected is the comparison of Here is some output from lldb at the point it actually fails:
|
This seems to have been fixed with ponyc 0.26.0. I dunno if we should close it, though. Maybe we still have some corpses in the basement? But hopefully any work on: #2982 will fix whatever is still hid. |
Maybe the remaining scope of this issue ticket would be to create a regression test to prevent it from being accidentally broken by future work? |
This compiles now when an else is added to the match: interface SafeOps[T]
fun addc(t: T): (T, Bool)
fun subc(t: T): (T, Bool)
class GenericSum[T: (Int & Integer[T] val & SafeOps[T])]
fun _plus_safe(x: T, y: T): (T, Bool) =>
x.addc(y)
fun sum(x: T, y: T): T ? =>
match _plus_safe(x, y)
| (let res: T, false) => res
| (_, true) => error
else
error
end
actor Main
new create(env: Env) =>
try
env.out.print(GenericSum[U8].sum(1, 2)?.string())
end But otherwise there is a compilation error. When @mfelsche said that this was working as of 0.26.0, did he mean with the If it's with the else, we can easily add a regression test for this and close this out. |
Yes, this one works with the |
In the following minimal example the match expression in
GenericSum.sum
claims that the first case cannot match although the type we match on is correct.This might have to do with using
addc
which is not part of theInteger
trait and only defined on the concreteInt
types. To have a generic function, wrappingaddc
, that works on allInt
types (which all haveaddc
) I had to create the interfaceSafeOps[T]
definingaddc
andsubc
in a generic way. I suspect that the issue is here but i cannot pinpoint it yet.http://playground.ponylang.org/?gist=a2138611ec2c1f4685a243a9d6e71737
Expected output:
Actual output:
The text was updated successfully, but these errors were encountered: