Structured Measurement Keys

[smitsanghavi]

A class that wraps the string measurement key, encapsulating any measurement key related logic and provides various utils for users. Phased rollout to eventually move away from manipulating strings to a well defined interface.

Is your design idea/issue related to a use case or problem? Please describe.
Currently, the measurement keys are plain strings. We need more structure and logic to the key itself to have a cleaner way to:

• Validate the keys (some characters are reserved to mean special things for e.g. ':' for nesting inside a CircuitOperation)
• Treating measurement keys created from Qubits as special type. Remapping qubits for a MeasurementGate should also remap these keys.
• Eliminate a lot of the brittle string parsing logic inside CircuitOperation and enable accessing different "levels" of a nested CircuitOperation more cleanly.
• Unlock more expressive implementations for Representing Classical Data, Feed Forward and Flow Control

Describe your design idea/issue
RFC: https://tinyurl.com/structured-measurement-keys
The initial part outlines potential approaches to go about this. The "Detailed Design" goes deeper into the preferred option (based on feedback from cirq-maintainers@) and the implementation/rollout plan for it.

[dabacon]

Is this done?

[daxfohl]

I think there was still a remaining task to rename and deprecate some protocols. While doing that we may want to see if we can speed up the default case for these protocols where nothing is implemented, perhaps removing some magic method options, or just creating an Operation.measurement_keys property, as the protocols do get called in tight loops during circuit construction.

[95-martin-orion]

@daxfohl, could you elaborate on the remaining work? IIRC, measurement_key_(objs|names) was the intended end state for the protocol renaming. I'm on board for optimizations, but those can be a separate post-1.0 issue.

[daxfohl]

Oh, I thought you wanted to get rid of the objs suffix. If not then it sounds like this is done.

…

On Tue, Jun 7, 2022, 11:46 AM Orion Martin ***@***.***> wrote: @daxfohl <https://github.com/daxfohl>, could you elaborate on the remaining work? IIRC, measurement_key_(objs|names) was the intended end state for the protocol renaming. I'm on board for optimizations, but those can be a separate post-1.0 issue. — Reply to this email directly, view it on GitHub <#4040 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG464NQJD2T6HLAEWRXHRLVN6KH3ANCNFSM43JOH5UQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[95-martin-orion]

Opened #5465 to track optimizations; closing this as complete.