[WIP] 3 arg update_func

Project.toml

@@ -1,7 +1,7 @@
 name = "SciMLOperators"
 uuid = "c0aeaf25-5076-4817-a8d5-81caf7dfa961"
 authors = ["Vedant Puri <[email protected]>"]
-version = "0.3.6"
+version = "0.4.0"
 
 [deps]
 ArrayInterface = "4fba245c-0d91-5ea0-9b3e-6abc04ee57a9"

src/interface.jl

@@ -5,21 +5,24 @@
 ###
 
 """
-$SIGNATURES
+    DEFAULT_UPDATE_FUNC(u, p, t) -> nothing
+
+    DEFAULT_UPDATE_FUNC(A, u, p, t) -> A
 
 The default update function for `AbstractSciMLOperator`s, a no-op that
 leaves the operator state unchanged.
 """
+DEFAULT_UPDATE_FUNC(u, p, t) = nothing
 DEFAULT_UPDATE_FUNC(A, u, p, t) = A
 
 const UPDATE_COEFFS_WARNING = """
 !!! warning
-    The user-provided `update_func[!]` must not use `u` in
-    its computation. Positional argument `(u, p, t)` to `update_func[!]` are
+    The user-provided `update_func` must not use `u` in
+    its computation. Positional argument `(u, p, t)` to `update_func` are
     passed down by `update_coefficients[!](L, u, p, t)`, where `u` is the
     input-vector to the composite `AbstractSciMLOperator`. For that reason,
     the values of `u`, or even shape, may not correspond to the input
-    expected by `update_func[!]`. If an operator's state depends on its
+    expected by `update_func`. If an operator's state depends on its
     input vector, then it is, by definition, a nonlinear operator.
     We recommend sticking such nonlinearities in `FunctionOperator.`
     This topic is further discussed in

src/matrix.jl

@@ -9,6 +9,7 @@ to `update_coefficients[!](L, u, p, t)`. Both recursively call the
 `update_function`, `update_func` which is assumed to have the signature
 
     update_func(A::AbstractMatrix, u, p, t; <accepted kwargs>) -> newA
+
 or
 
     update_func!(A::AbstractMatrix, u ,p , t; <accepted kwargs>) -> [modifies A]