Decide whether to lock function arguments at compile time

[oremanj]

An attempt at the static locking determination that I suggested in #695 (comment). Note this PR is against the free-threaded branch.

Behavior differences from the free-threaded branch without this change:

• it is no longer possible to do nb::arg().lock(false) or .lock(runtime_determined_value); this could be re-added by restoring cast_flags::lock and checking the arg_flags at runtime, but I didn't think it was worth the complexity
• we no longer prohibit locking self in __init__; changing this would also require restoring cast_flags::lock, and it's not clear what benefit it would have (sure the lock is somewhat superfluous but do we really care?)

[wjakob]

This is great! It is certainly better than my runtime solution. Two thoughts:

1. You had mentioned in the prior PR that it's unfortunate if nb::arg().lock requires the complex function dispatch loop. Does this adress that Issue? I am thinking that some runtime check in nb_func_new is still needed to discover that the simple dispatch base case still applies despite argument annotations being present.

2. All the duplication between arg, arg_v, arg_locked, and arg_locked_v seems a bit much with this further compile-time distinction. Would it be better to have single a template class?

template <bool IsLocked, bool HasValue> struct arg {
    const char *name = nullptr;
    PyObject *value = nullptr;
    // ...

   arg</* IsLocked = */ true, HasValue> lock() { return { name, value, ... }; }
   template <typename T>
   arg<IsLocked, /* HasValue = */ true> operator=(T&&x) {... }
};

All the code processing the various args could then match on the arguments.

[wjakob]

After thinking more about it, perhaps having non-template arg variants is also better. This class is used very often in bindings, and having a template here might affect compile time costs. I am not sure.

[wjakob]

OOps, I forgot to send off these comments.

[oremanj]

You had mentioned in the prior PR that it's unfortunate if nb::arg().lock requires the complex function dispatch loop. Does this adress that Issue? I am thinking that some runtime check in nb_func_new is still needed to discover that the simple dispatch base case still applies despite argument annotations being present.

Correct, that's separate. This PR makes that improvement possible, but doesn't implement it.

All the duplication between arg, arg_v, arg_locked, and arg_locked_v seems a bit much with this further compile-time distinction. Would it be better to have single a template class?

If we had another axis of variation I would definitely want to go for the template. I think the current case is borderline, and don't mind changing it if you prefer the template, but I think the duplication still winds up a little easier to understand. For backcompat we would need to keep the arg and arg_v names regardless, so the template would be something like arg_t with arg/arg_v as aliases for particular instantiations; then we'd need a metafunction to detect "any instantiation of arg_t", etc.

[wjakob]

Thanks a lot!