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
Either provide a function to tell whether two settings maps are identical, or guarantee that the integer handles are equal whenever the maps are identical.
I don't expect this "identical" operation to be used for implementing the Eq trait == on the auto-splitter side. My intended use case would be to allow a load_if_changed function on the auto-splitter side.
For example:
I load the settings map and call it A, and then load it again on a future tick and call it B.
If the settings map has been unchanged for that time, then either A and B should be different handle integers but which "identical" returns true for, or they should be guaranteed to be the same handle integer, in which case there would be no need for a special "identical" function.
The text was updated successfully, but these errors were encountered:
Complication: if "the settings map" has been unchanged, but A has been changed by the auto-splitter, it would be wrong for the 2nd load B to have the same handle integer as A.
Related complication: if an auto-splitter loads A, then loads B which is unchanged, and then mutates A. They would not expect B to be changed.
So maybe making the integer handles equal is a bad idea, and an "identical" function is needed after all.
Either provide a function to tell whether two settings maps are identical, or guarantee that the integer handles are equal whenever the maps are identical.
I don't expect this "identical" operation to be used for implementing the
Eq
trait==
on the auto-splitter side. My intended use case would be to allow aload_if_changed
function on the auto-splitter side.For example:
I load the settings map and call it
A
, and then load it again on a future tick and call itB
.If the settings map has been unchanged for that time, then either
A
andB
should be different handle integers but which "identical" returns true for, or they should be guaranteed to be the same handle integer, in which case there would be no need for a special "identical" function.The text was updated successfully, but these errors were encountered: