In reply to @piegames:flausch.social
The would probably not mesh well with future performance optimisations

So one issue I'm seeing is that "best effort" or "marginal effort" function equality checking will tend to be unstable because the set of functions we can determine equal, and the set of functions that we can distinguish between will both fluctuate based on our implementation.

How's this for a plan?

(a) fix nixpkgs so it doesn't use function equality checking
(b) output a warning when people try to use function equality checking. something to the effect of "this is unstable and exists for backwards compatibility"
(c) maintain an unstable version of function equality checking, that is only guaranteed to work in situations where function equality currently works.

We can introduce a flag --no-function-equality like we have --no-url-literals

That way people can continue to evaluate old versions of nixpkgs, but people are unlikely to depend on how the features is implemented now (certainly in nixpkgs), so we are free to adjust it to new implementations, even though it breaks edge cases, since nobody will be using those edge cases.

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