You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To be honest, I don't think this is a good solution because mir lowering would be bloated if we continue to pack this kind of ad-hoc implementation into the phase. I think providing Eq or PartialEq trait would be the simplest and best solution.
Yes, PartialEq trait would be my preferred solution as well. But in order for that to be possible we need to find out how to support generics / traits to work with all types and not just structs. That's actually one of the issues that if we crack them will enable a lot more sophisticated features in the language. Currently this is blocked because in the analyzer for a generic type T we can not figure out the location of the type and hence default it to memory for now. You mentioned you had some ideas how to get rid of the location specific code in the analyzer. I would appreciate your thoughts and ideas how to advance that.
Now that we have support for Self it should be able to define PartialEq and then use that for == and !=. However, to be helpful with complex types such as tuples we will probably need to have macros and use them the way Rust does because otherwise people would have to implement PartialEq by hand for each specific tuple. But I believe the current rewrite lead by @Y-Nak already clears the way for such kind of macros.
What is wrong?
We currently can't easily compare tuples with the
==
operator. E.g. the following doesn't work.Instead what we have to do is:
How can it be fixed
We can probably tackle that at MIR loweringMake
PartialEq
andEq
traits possible and use them for this.The text was updated successfully, but these errors were encountered: