Temporary GridDevice.qubits property

[verult]

@mpharrigan
cc @dstrain115

[mpharrigan]

I feel like in most cases the quote-unquote "correct" migration would be to change the entire code-base to expect DeviceMetadata objects at API boundaries instead of Device. Unfortunately, this is a rather large and disruptive change that would have to be done throughout a codebase. What do you think @MichaelBroughton ?

[MichaelBroughton]

This is a tricky one. The way I see it is any cirq-core features we make ought to make use of cirq.Device or a subclass of cirq.Device that is inside of cirq-core. That way any reasonable vendor device could also be used with those features. Specific Vendors who implement their own device related functionality can then have their APIs expect cirq_<vendor>.VendorDevice (which is kind of what we do now with cirq_google.GridDevice and some of our placement routines like anneal.py). I actually think passing around the devices themselves with their type distinctions is the right call vs the metadata objects which may or may not adhere to the same type distinction as devices. Plus it's not too hard to make a library method do a quick check like:

if device.metadata:
  _do_some_functionality_based_on_metadata_

_do_other_stuff_.

[mpharrigan]

I imagine most of the code will look like

if device.metadata is None:
  raise ValueError("need qubits")

[verult]

Do we want to consider making it non-Optional? My take is a Device without qubit information probably can't do much

[mpharrigan]

@MichaelBroughton

[verult]

Chatted with @MichaelBroughton offline - not all devices have a well-defined qubit set and connectivity graph so the consensus during the design phase was to leave it optional.