Should _resolve_value pass None through?

[zchen088]

Is your design idea/issue related to a use case or problem? Please describe.
In some cases, we'd like to be able to resolve a parameter to None to signal that the gate should use "default behavior". Previously, None was being used to signal recursion in the parameter resolution code, but this is no longer the case, so it seems like we should be able to do this.

Describe your design idea/issue
This would be relatively simple change. In _resolve_value:

Cirq/cirq/study/resolver.py

Line 240 in 47f5908

def _resolve_value(val: Any) -> Any:

, we would simply check is None and pass that on through. What I'm not sure about is, are we relying on None not being pass through anywhere else in Cirq? For example, is there code which assumes that, if the value is None, don't resolve it?

[maffoo]

This seems reasonable to me. I think basically all "primitive" values should get passed through _resolve_value since they obviously can't meaningfully be resolved to anything else. Could you give a snippet showing the current behavior and how you'd like things to work?

[95-martin-orion]

What I'm not sure about is, are we relying on None not being pass through anywhere else in Cirq? For example, is there code which assumes that, if the value is None, don't resolve it?

I'm not aware of anything like that. My current expectation is that something like cirq.X ** phi, params={phi: None} would fail, but I don't think any Cirq code actually relies on this. However, the expectation of failure is much stronger for cirq.X ** phi, params={} (i.e. phi is unassigned) - that should continue to fail after this change.

If the requirement isn't specifically for None to provide default behavior, I might suggest using a stub object like _RecursionFlag instead.

[verult]

Marking as triage/accepted based on comments.

[dstrain115]

I will go ahead and take this on since there hasn't been movement on this in two months. Please let me know if anyone has already started on this.