Skip to content
This repository was archived by the owner on Jan 12, 2024. It is now read-only.
This repository was archived by the owner on Jan 12, 2024. It is now read-only.

API: Consider deprecation/exclusion of GetQubitsAvailableTo{ Borrow | Use }() #418

@kuzminrobin

Description

@kuzminrobin

(Links GetQubitsAvailableToBorrow(), GetQubitsAvailableToUse())

Discussion (key items):

[12:25 PM] Bettina Heim
Hi all,
We are in the process of adding the necessary QIR runtime functionality to support Q#. As part of that, I wanted to gather your insights regarding whether and how QubitsAvailableToBorrow and QubitsAvailableToUse are used. Right now, I am aware that the C# tracer uses them, but I am not sure anything else does. Are you aware of where else these may be used? Are these useful to keep or are these something that we might use internally only as part of the simulator but not necessarily expose in Q#? [12:27 PM] Chris Granade (THEY/THEM)
I don't know of anything else that uses them, no, but in part that's a bit circular. Most simulators don't suppose those operations, such that the utility for users is somewhat limited.
[12:28 PM] Bettina Heim
The primary use I see is for quick experimentation, but maybe there are better ways to do that without exposing them in Q#.
[12:29 PM] Chris Granade (THEY/THEM)
I'd be in support of deprecating and removing; an eventual application (e.g.: dynamic or virtual qubits — very cool stuff if you haven't seen!) would benefit from a better implementation anyway.
[12:34 PM] Stefan Wernli
I too would be in favor of simplifying by removing them. QIR simulation is unlikely to use the same qubit manager design as C#, and as of now there is no partner hardware or planned first party simulator that would use it.
[6:28 PM] Chris Granade (THEY/THEM)
As that would be a change to the API surface, we will want to make sure it's reviewed in the Q# API Review process so that the community has a chance to see our reasoning and to offer feedback. Robin, would you be willing to file a quantumlibraries issue, so that I can add it to our scheduling board? The next review is Thursday am, should be able to decide on it at that point. In the meantime, I think we can still proceed as-is under the understanding we may need to revert PRs should the change not be approved in review.

Metadata

Metadata

Assignees

Labels

Area-APIIssue concerns the API design of a library, such as style guide or design principles adherence.Pkg-StandardIssue relates to the Microsoft.Quantum.Standard package.Resolution-DoneIssue closed because work item completed.

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions