Policy and uncertainty

As soon as several implementations can answer the same question, we also need to let them disagree about what they can provide. An image provider might not implement convolution. Another might implement it but refuse a particular kernel size. A source declaration might eventually supply the requested capability, but still depend on something we haven't resolved.

Returning a null pointer for all three would make the caller guess what happened. Worse, it would encourage the caller to keep looking underneath the provider until it found something that appeared to work, bypassing the policy that refused the request.

Letting the answer carry its meaning

Semantic negotiation distinguishes Satisfied, Unknown and Rejected. Unknown leaves the question undetermined: the contract may be unfamiliar, or the provider may lack the evidence needed to answer. Rejected explicitly refuses the request. Only Satisfied supplies a usable binding.

A composing policy may delegate an Unknown question through its own authority. That doesn't give the consumer permission to inspect the underlying receiver or ask around the policy. The interface encountered remains responsible for the answer and the conditions under which it is supplied.

There is a separate vocabulary when the answer itself is an Abstract. None means absence has been established. Unknown means the conceptual answer is still unsettled. Constant supplies an explicit invariance promise. A query can succeed and return None, just as it can succeed and tell us that the answer remains Unknown. Neither case is a failed attempt to obtain an interface.

Consider a declaration whose type depends on another declaration being evaluated. Treating Unknown as absence would allow a consumer to make a permanent decision from incomplete evidence. Treating every absent answer as Unknown would leave it waiting for information that the owner already knows will never arrive.

Asking through a policy

An Alias is transparent forwarding. A policy is allowed to change what can be observed, which means the consumer has to keep asking through the policy it was given.

In the Godot example, a script provider can offer convolution and still limit the amount of synchronous work it accepts. A smaller kernel may succeed while a larger one is refused. The underlying operation's existence doesn't authorize us to reach around that limit, even if another native interface happens to be reachable from the same object.

Knowing when an answer can be reused

Successful binding doesn't make the answers from subsequent calls constant. Their validity depends on the owner's stability promise, as described in Observation and reuse. That chapter also covers the scheduling contracts needed to await an unsettled answer.

The concrete interfaces are in Abstract and its graph policies.