Thanks!
Without this type annotation/conversion, f’s output type is being correctly inferred on my machine. I don’t think there’s any need for concern one way or the other, but are you sure this is the point in your codebase where type stability is being lost?
Yeah. The tricky thing with my codebase SymbolicRegression.jl is that it is set up to allow arbitrary user-defined operators, loss functions, and constraints. However, sometimes user-defined operators introduce their own type stability for whatever reason (a lot of new Julia users are introduced via the PySR frontend, wanting to customize things for their problem), so I have noticed that it helps a lot if I just enforce type stability on their behalf. Then, the user won’t experience a weird slow-down and have to learn these advanced concepts in Julia just to use my library efficiently.
Right now SymbolicRegression.jl only allows for scalar operators, but I’m slowly expanding type constraints to allow for vector operators. So that’s where my question about specifying container types comes from.