Extension: Variable Pointers

[PhilMiller]

The current GetValuePtr routine is modestly under-specified with regards to the validity of the returned pointer, and what it means if a model does or doesn't return a pointer for a given variable.

I propose making the semantics more explicit through the use of variable sets. Specifically, variables in a set bmi:stable_pointers can be expected to yield pointers that are valid for the lifetime of the model, and variables in a set bmi:transient_pointers can be expected to yield pointers that are valid for immediate use, but may be invalidated by calls to any other BMI routine on that model.

The example I have in mind for transient pointers are variables backed by a dynamically resizable array or vector, which exist in at least a few models I'm aware of.

Transient pointers would still be useful in model coupling, calling auto ptr = modelA->GetValuePtr("foo"); modelB->SetValue("foo", ptr); and avoiding an intermediate buffer and copy in the driver.

[PhilMiller]

(note: I haven't actually committed any changes toward this end yet, beyond the variable sets PR on which this is based)

[PhilMiller]

I initially thought of this as a possible extension. It could still be, if we want to drop GetValuePtr() from the core BMI specification, and have one fewer thing for 'naive' model implementers to stub out with BMI_FAILURE returns or throws of "unimplemented" exceptions. In that case, I would tentatively propose to call the sets bmi:pointers:stable and bmi:pointers:transient, with the extension called bmi:pointers

[PhilMiller]

In discussion with Austin, I concluded that GetValuePtr, however it persists, should be in an extension and not core BMI. Among other things, this potentially plays into core BMI being more fully compatible with Rust bindings that follow its strict semantics.