MutationFunctionWrapper which ignores the output?

[ChrisRackauckas]

A common scheme in a lot of scientific computing is to require the user's input function to be a mutating function. You see this in DiffEq and optimization for example. In these cases, we essentially take that the user's return type is Void and do not use it. In these cases, is there any issue with simply opening up the return type to Any?

Or is it better to strictly type the function wrapper by putting a thin wrapper over the user's function?

function f(t,u,du)
   du[1] = 1.0 * u[1] - 3.0 * u[1]*u[2]
   du[2] = -3 * u[2] + u[1]*u[2]
end
f_wrap = (t,u,du) -> (f(t,u,du);nothing)
u = rand(2)
du = zeros(2)
FunctionWrapper{Void,Tuple{Float64,typeof(u),typeof(u)}}(f_wrap)(0.0,u,du)

Or is there a better solution?

[ChrisRackauckas]

Another question: is the return type doing anything more than a type assertion? I see that it tries to convert like a type assertion does, but I don't quite understand what the actual generated function code is doing. If it is just a kind of type assertion under the hood, is there a performance different between putting a function a non-strict type like

immutable MyFunction
   f
end

and using a FunctionWrapper and putting a type assertion on the return in every use?

[yuyichao]

Using Void to ignore return value has been the plan all alone and I thought I've already implemented it..... I guess I never actually needed it and never implemented them.

If it is just a kind of type assertion under the hood, is there a performance different between putting a function a non-strict type like

I assume it's obvious now but yes, there're a lot of differences.