Should `==` over `ComposedFunction` support `missing` as usual

[nsajko]

The current behavior is:

julia> (sin ∘ missing) == (sin ∘ missing)
true

But it seems like we should actually have == return missing in this case? This is because missing basically represents a wildcard function here, the way I interpret it at least. This would be analogous to, e.g.:

julia> (missing, 3) == (missing, 3)
missing

This is a special case to consider for #53853.

Not sure if I should label this for triage, but it'd be nice to get a quick decision here, given that it's relevant to @jw3126's PR #54877.

[adienes]

please, no

I think Missing should stay in its statistics corner and only propagate in statistical contexts

Imo it already propagates through far too many functions.

[nsajko]

For better or worse, the ternary logic including missing is part of the semantics of ==.

[adienes]

wait, why does missing work with ∘ in the first place? it's not a function

I'd sooner special case an error path for ∘(::Missing) than make it propagate.

[jariji]

But it seems like we should actually have == return missing in this case?

If ==((;f1,g1)::ComposedFunction, (;f2,g2)::ComposedFunction) = f1 == f2 && f2 == g2, then this should return missing. I don't think there's another result that makes sense.

why does missing work with ∘ in the first place? it's not a function

∘ takes any value, it doesn't know if they're callable until it tries to call them. That's basically the julia style. If it's necessary to know statically that there's a problem then JET will detect the problem at the problem where the invalid call occurs, not where the construction occurs. Just like you can make a list of [abs, exp, missing] and it doesn't error until you try to call them.

[jw3126]

If ==((;f1,g1)::ComposedFunction, (;f2,g2)::ComposedFunction) = f1 == f2 && f2 == g2, then this should return missing. I don't think there's another result that makes sense.

I don't think so, && will error on missing first argument:

julia> missing && true
ERROR: TypeError: non-boolean (Missing) used in boolean context
Stacktrace:

[jariji]

Ah yeah, true && missing returns missing and missing && true errors. So if the implementation is structural, the result might depend on the order in which the components are checked. ComposedFunction components have an obvious "order" to them (namely, application order), so it seems fine to implement == structurally using the application order.

I don't like the idea of introducing a special case error specifically to make sure missing doesn't propagate: Missing is the type designed for propagating missingness, after all. 🙂

If a user wants to create a collection of callables, some of which some are missing, and then ∘ them together, I think they should be able to do that, and expect the behavior to compose too, following the specifications of the components (==, ComposedFunction, and Missing), without needing to also consider a special rule that only takes effect when these three things are combined.