Prior to this commit, trying to compare two structs for identity equality (===/!==) would raise an exception at compile time, because this case was not implemented.
There are still other cases that are not implemented (such as dealing with the case where one side is a boxed value, and the other side is an unboxed value).
But those are left to be implemented at a later time.
Particularly, it's expected that we'll soon redesign the way equality works in Savi (
see https://savi.zulipchat.com/#narrow/stream/294897-general/topic/Element-wise.20Array.20comparison.20fails ) so that the compiler will automatically generate a default == implementation for all types
(which can be overridden by the user). At that time, we could also generate a === implementation that cannot be overridden, which would allow us to simplify the code being modified here in this commit, as we could change this call site to a basic method call (for the === method) after type comparison, rather than coding the field-wise comparison as LLVM IR as we did here, and sidestepping issues with boxed/unboxed things, as the typical virtual call mechanism will take care of resolving the appropriate unboxed values into method args.
Prior to this commit, trying to compare two structs for identity equality (
===/!==) would raise an exception at compile time, because this case was not implemented.There are still other cases that are not implemented (such as dealing with the case where one side is a boxed value, and the other side is an unboxed value). But those are left to be implemented at a later time.
Particularly, it's expected that we'll soon redesign the way equality works in Savi ( see https://savi.zulipchat.com/#narrow/stream/294897-general/topic/Element-wise.20Array.20comparison.20fails ) so that the compiler will automatically generate a default
==implementation for all types (which can be overridden by the user). At that time, we could also generate a===implementation that cannot be overridden, which would allow us to simplify the code being modified here in this commit, as we could change this call site to a basic method call (for the===method) after type comparison, rather than coding the field-wise comparison as LLVM IR as we did here, and sidestepping issues with boxed/unboxed things, as the typical virtual call mechanism will take care of resolving the appropriate unboxed values into method args.