Repository: quantumlib/Cirq

Issue #3390: Stronger typing for cirq.resolve_parameters
Created: 2020-10-05T18:43:46Z
Is your feature request related to a use case or problem? Please describe.
Currently the type of cirq.resolve_parameters is:
def resolve_parameters(
        val: Any,
        param_resolver: 'cirq.ParamResolverOrSimilarType') -> Any:
Since the result is Any, we lose type information whenever we resolve parameters. However, for many important cirq objects (gates, operations, moments, circuits) it is typically the case that resolving parameters returns an object of the same type. To avoid losing type information it'd be nice to have a signature like:
def resolve_parameters(
        val: T,
        param_resolver: 'cirq.ParamResolverOrSimilarType') -> T:
Describe the solution you'd like
Not sure the best way to do this. We probably need a separate top-level method for type-preserving parameter resolution, and a separate _special_method_ that classes can implement to indicate that their type is preserved under parameter resolution. It would seem to me desirable to make type-preserving resolution be the default since as I said that is most common for cirq types; the exceptions are low-level things like sympy symbols whose type can obviously change when resolved, but which are not cirq types and typically don't need to be resolved directly. One possibility would be to leave cirq.resolve_parameters as it is and add cirq.resolve as a type-preserving resolution function.
[optional] Describe alternatives/workarounds you've considered
Can use type casts to recover type information after resolution, but this is ugly and error-prone. Can also have more specifically typed methods on particular classes that can be called instead of the generic cirq.resolve_parameters protocol, but this adds boilerplate and highlights the problem with the resolution protocol itself.
What is the urgency from your perspective for this issue? Is it blocking important work?
P3 - I'm not really blocked by it, it is an idea I'd like to discuss / suggestion based on principle
I think the actual amount of work needed to implement this will be modest, once we settle on a strategy.

Duplicate issue #3391: Stronger typing for cirq.resolve_parameters
Created: 2020-10-05T18:44:16Z
Is your feature request related to a use case or problem? Please describe.
Currently the type of cirq.resolve_parameters is:
def resolve_parameters(
        val: Any,
        param_resolver: 'cirq.ParamResolverOrSimilarType') -> Any:
Thus, by resolving parameters we lose type information. However, for many important cirq objects (gates, operations, moments, circuits) it is typically the case that resolving parameters returns an object of the same type. To avoid losing type information it'd be nice to have a signature like:
def resolve_parameters(
        val: T,
        param_resolver: 'cirq.ParamResolverOrSimilarType') -> T:
Describe the solution you'd like
Not sure the best way to do this. We probably need a separate top-level method for type-preserving parameter resolution, and a separate _special_method_ that classes can implement to indicate that their type is preserved under parameter resolution. It would seem to me desirable to make type-preserving resolution be the default since as I said that is most common for cirq types; the exceptions are low-level things like sympy symbols whose type can obviously change when resolved, but which are not cirq types and typically don't need to be resolved directly. One possibility would be to leave cirq.resolve_parameters as it is and add cirq.resolve as a type-preserving resolution function.
[optional] Describe alternatives/workarounds you've considered
Can use type casts to recover type information after resolution, but this is ugly and error-prone. Can also have more specifically typed methods on particular classes that can be called instead of the generic cirq.resolve_parameters protocol, but this adds boilerplate and highlights the problem with the resolution protocol itself.
What is the urgency from your perspective for this issue? Is it blocking important work?
P3 - I'm not really blocked by it, it is an idea I'd like to discuss / suggestion based on principle
I think the actual amount of work needed to implement this will be modest, once we settle on a strategy.

Closing comment (2020-10-05T18:44:35Z): Dupe of #3390