I would actually prefer to name the fields to e.g. outer, inner instead of f,g. It is hard to remember if this models f∘g or g∘f.

I'm somewhat neutral about the choice of the field names. I see f and g as something like x and y. It's technically arbitrary but I've seen it many times so I don't think it's super hard to guess the ordering.

Just as a note, one (rather weak) upside of keep using f and g is that we can define ComposedFunction for older julia versions as done in DataFrames.jl (JuliaData/DataFrames.jl#2274 (comment)). However, it doesn't matter much since 1.6 soon will be the LTS (and we can even define getproperty for the closure in Compat.jl).

I think the order is not easy to guess at all. Just have a look at the wikipedia article. There the order g∘f is more dominant, which is opposed to the current order we use.

My personal first guess was btw g∘f.

Well, I sometimes get inner/outer opposite somehow (though this is probably just me). Since you can always flip the arrows (and which direction feels natural depends on the context), I'm not sure if there are truly unambiguous names for them. But I'm likely nitpicking. I agree inner/outer is more descriptive for function composition.

With outer, inner it is at least clear that c::ComposedFunction talks about c.outer(c.inner(x)). With f,g it is unclear whether we are talking about c.f(c.g(x)) or c.g(c.f(x)). Remembering the direction of arrows is an independent problem that comes up in both scenarios.

Btw, I also get inner outer wrong sometimes, but I can usually recover by pure reasoning without having to dig up the source.

I agree it's easier to remember and be confident which function is applied first with inner/outer. I think I'm in the team inner/outer now. How about renaming them in this PR and see the reactions of other reviewers?

For the little it is worth, I think f and g are fine and their exact interpretation can be clarified in the docstring. That way there doesn't need to be any work on Compat.jl or in other packages.

If you stick with inner and outer, then I think line 881 needs to change:

Represents the composition of two callable objects `f::Outer` and `g::Inner`.

No, f and g are confusing, we should not force people to look up the docstring all the time. Also @tkf has a PR to compat
JuliaLang/Compat.jl#720 and supporting f and g is the easy part of that code.