SciML
Returning a Dict type instead of a tuple
Wouldn't it be better if we returned a Dict type instead of a tuple? In particular, what would be the downsides of returning
`Dict('t'=>tout,'y'=>yout)`
or
`Dict(:t=>tout,:y=>yout)`
(sorry, I don't know which one is the canonical way) instead of just
`(tout,yout)`
? Is it about performance issues related to creating the Dict with every iteration?
One advantage of this system would be that we would be able to unify the outputs of different solvers, e.g. DASSL returns (tout,yout,dyout). One could also think about adding solver-specific data like the number of rejected steps, jacobian computations, step size etc. without causing API incompatibilities. I know that some of these functions can be implemented via function side effects, but there are some that cannot be accessed that way (e.g. rejected steps) and it would be nice to have them all in one place. Besides, such data could be immensely useful for testing (one could think of improving the results presented in @mauro3's test suite https://github.com/mauro3/IVPTestSuite.jl).
I think the current behavior is mostly for convenience and "compatibility" with other languages. Instead of returning a Dict, I would prefer to have types which contain the results and some status information about the procedure. Having a "result type" methods can decide which information they want to pass to caller, but we can also specify a minimum of information all methods have to provide.
@acroy, that would be an even better approach. Any ideas on how such type should look like? What is the bare minimum for returned data and what is just a recommendation?
As this works:
julia> f() = 3,4,5
f (generic function with 1 method)
julia> a,b=f()
(3,4,5)
julia> a
3
julia> b
4
How about keeping tout and yout and add a Results object last? If a user cares he can keep it, otherwise it doesn't impact him?
We could add an option whether to generate Results type at all, if it would turn out to generate an overhead.
On the other hand, this approach would lead to two different API styles, some programs would only use Results and some would use (t,y), it might be difficult to support both in the long run.
One more thing, should the iterator version of the solver also return Results but containing just a single step?
Just a short comment returning a tuple should be more performant since Julia is able to infer the return type. With a dict you may introduce a type instability by accident. (If yout and tout are not of the same type)
