An API for letting the c_ function to leave information for its u_ function if it's called immediately after.

[krivit]

Recall the sqrt(triangles) example. The c_ function must compute the change statistic for the number of triangles due to the proposed toggle. If this toggle is then accepted, the u_ function must repeat this calculation to update the stored number of triangles. This is both code duplication and waste of computing time.

A simple API change would be to create a new container element on the ModelTerm struct, e.g.,

struct {
  Vertex i, j;
  void *payload;
}

that the c_ function is allowed to write to, recording the toggle information and whatever data structure the c_ function wants to pass along.

Then the u_ function must check that it's the same toggle, use the information, then set i and j to 0 so that on the off chance that it is called again without a c_ call in between, it'll know that the information is not valid.

The f_ function, as in case of the other storage, can free the payload if not NULL and then free the struct.

[krivit]

In principle, we can take a libertarian approach, and just remove the statement from the specification that c_ functions are not allowed to modify mtp->storage. (There is already nothing preventing them from doing it.)

[krivit]

The libertarian approach appears to work. It may make sense to macrofy.

This does not address an arguably more common pattern in which the storage (e.g., number of triangles) is maintained by an auxiliary. This is a very common pattern for term operators, which use an auxiliary to maintain the transformed network.

In those situations, both the operator's c_ function and the auxiliary's u_ function must calculate the (hypothetical or imminent, respectively) change in the state of the auxiliary's public storage as a result of the network change. I can see two approaches:

1. The auxiliary could provide a callback function pointer for this, which would modify its private storage.
2. The auxiliary could provide a static inline function or even a macro that would modify its public storage.

Approach 2 is probably better, since it's likely to produce less overhead from a function call, and, also, Approach 1 requires the auxiliary to somehow inform the client where to find it, which means that its public storage is going to have to be augmented anyway.

If multithreaded statistic calculation is in effect, both approaches have potential for race conditions, unless a locking mechanism is implemented, which would result in its own overhead.