## GridFunction is too strict about derivatives

I've stumbled over a nasty usability issue with `GridFunction`

s: The concept for grid functions requires the function to be both localizable and differentiable (by proxy, the `LocalFunction`

must be differentiable as well). Our reasoning back then was that these objects will typically be differentiable, so IIRC we said it should be fine to always make them differentiable.

But Peter has been playing with dune-functions a little bit. He wanted to write his own `GridFunction`

that takes an analytic function, interpolates it into some function space on `bind()`

and then uses the interpolant for evaluations on the bound element. For this you need to write both the global and the local function. That works fine, but he failed when trying to assign the function to the polymorphic `GridFunction`

wrapper because of missing derivatives.

I tried to work around the problem by implementing the same hack as in the `AnalyticGridViewFunction`

, but that doesn't work either. As it turns out, you cannot assign an `AnalyticGridViewFunction`

to a polymorphic `GridFunction`

wrapper. The problem lies in the fact that the polymorphic wrapper insists on pre-instantiating the derivative, and the derivative itself is another `GridFunction`

, which triggers a recursion until the type of the derivative is equal to the polymorphic interface type. To add insult to injury, `isGridViewFunction(AnalyticGridViewFunction)`

actually returns `true`

, because it doesn't instantiate all the things.

Funnily enough, all of the polymorphic wrappers actually state in their constructors that it should be possible to pass in a function without `derivative()`

and that calling `derivative()`

on the wrapper will then throw an exception.

I'll push a MR with a proposed solution.