that's a historical accident and one that I fail to convince myself you can rely on in good faith to write production Nix code

Clarification: "that" here is referring to functions comparing non-equal when they are, in fact, equal?

I would be in favor of making that comparison true even if it was not before.

I think this is fine as long as it's a one-way ratchet. My concern is that we will make something compare equal (that is equal), people start depending on that behaviour, and then later change the structure again in a way that makes those compare non-equal. This is why I was proposing we mark this feature as unstable (maybe unstable isn't the right word, because there's no intention to make it stable in the future)

I think we're somewhat lucky in that the state of affairs we need to be backward-compatible with at the moment (pointer equality in CppNix), is very weak (in the sense that very few things compare equal), so it's easy to maintain backward compatibility with it. If we add more things to the relation, it will become harder to change things in ways that maintain backward compatibility. (where by backward compatibility i mean things that used to compare equal continue to compare equal, but not necessarily the inverse)

I am quite against reverting the whole thing

Clarification: by "the whole thing" you're referring to pointer equality?

expose builtins to construct your own flavor of pointer equality to pass to the scoped import to make broken code run again.

Wouldn't what we can expose be super dependent on implementation details?

Clarification: "that" here is referring to functions comparing non-equal when they are, in fact, equal?

"that" refers to any (pointer) equality that evaluated to false when it should have evaluated to true

I think this is fine as long as it's a one-way ratchet. My concern is that we will make something compare equal (that is equal), people start depending on that behaviour, and then later change the structure again in a way that makes those compare non-equal. This is why I was proposing we mark this feature as unstable (maybe unstable isn't the right word, because there's no intention to make it stable in the future)

yeah this sounds like a permanent xp feature

Clarification: by "the whole thing" you're referring to pointer equality?

i'm referring to the maximal sharing work that was done in Lix

Clarification: by "the whole thing" you're referring to pointer equality?

i'm referring to the maximal (well it's not exactly maximal) sharing work that was done in Lix

Wouldn't what we can expose be super dependent on implementation details?

idk, we can formalize what is pointer equality

In reply to @raitobezarius:matrix.org
well the other thing was a regression no?

In reply to @raitobezarius:matrix.org
This is going into the pennae's direction from my understanding

no practical value to offer a real == for fns

except backward compatibility, right?