Should we deprecate Circuit.device?

[mpharrigan]

Currently, each and every cirq.Circuit has a device attribute which defaults to UnconstrainedDevice. I think the original idea was that validation of device constraints would happen during circuit construction.

1. This strikes me as strange. It makes more sense to me to have a device validate a circuit.
2. Separating validation from circuit construction would permit more useful validation functionality. For example: instead of erroring out at the first bad gate, you could return a list of all the problems found and/or suggestions on how to fix problems identified
3. In my experience, no one uses cirq.Circuit.device. You could argue that this attribute is a good marker for how the circuit has been compiled (i.e. what it's targeted at) but the provided compilers / circuit transformers don't set this property on the resultant circuit.

xref #3244

[viathor]

I agree that the only good reason for this attribute is as a marker for what device was targeted when the circuit was compiled. Perhaps we should rename it to targetedDevice, default it to None and modify compilers to actually set it. That said, I could support outright deprecation, too.

[balopat]

I wonder why it was introduced in the first place - maybe @dabacon or @Strilanc can provide some color?

[balopat]

Discussed on Cirq Cynque: it sounds like this is ready to be deprecated, especially if it causes confusion to users when creating optimizers.

[balopat]

ping @dabacon please chime in!

[mpharrigan]

The problems with keeping it are

1. since it's neglected, new features sometimes introduce bugs when the developer forgets to think about this parameter (think: serializing circuits, circuit transformers)
2. it's unclear how circuit transformers should deal with the device attribute. Forward it? set it to something indicating the target of the transformation? Set it to UnconstrainedDevice?

[dabacon]

It was originally designed to do validation, i.e. to enforce that your circuit could run on the given device.

I think I'm the one who advocated the mistaken pattern of using it during circuit construction. There was a nice use case where you could use it to gracefully handle the "not parallel ops" in the old Bristlecone architecture.

I think it should be deprecated as well. (I suspect there is a major problem in that we didn't separate construction from use in the Circuit object and so it might be natural to have specific constructor patterns for circuits, they shouldn't live in circuit.)