Attendees (in order by username): @bettinaheim, @cgranade, @msoeken.
Proposal: #448
Discussion:
- Rename
FactorialD
toApproximateFactorial
? - Change input type for
ApproximateFactorial
toInt
. - Type suffixes are good to keep for future expansion and for consistency.
Consensus: Approve with above change to FactorialD
.
Proposal: #377
Discussion:
- Cannot make this change without breaking code.
- Proposed ordering for
ApplyIf
consistent withApplyIfElse
, more closely follows Q# style guide. - Worth the breaking change to offer a more consistent experience to developers.
Consensus: Approve as written, but defer implementation until next breaking changes needed anyway.
Proposal: #453
Discussion:
@Stable()
implies two purposes: to mark stability, and to mark when that item became stable.- What should we do with existing (unlabeled) functions/operations/types?
- Leave unlabeled, but start auditing in run-up to Q# 1.0 and marking things we're good with being in 1.0 as
@Stable()
. Goal to have entire stdlib covered with@Stable()
by 1.0.
- Leave unlabeled, but start auditing in run-up to Q# 1.0 and marking things we're good with being in 1.0 as
- Modify
@Unstable()
to require link to GitHub issue for tracking discussions.- Good to enforce at compile time that link goes to tracking discussion — helps avoid things staying as unstable without either promoting to stability or removing.
- Could even imagine IRewriteStep that checks that links in
@Unstable()
resolve to open GitHub issues.
- Should we add attributes to API before compiler support, or gate on microsoft/qsharp-compiler#998 having completed?
- Good to at least be able to document
@Unstable
and@Stable
. - microsoft/qsharp-compiler#998 could be good for external contribution ("help wanted" issue tag).
- Good to at least be able to document
- Action item: Double check that "unstable" is broadly used in this connotation.
Microsoft.Quantum.Documentation
is a reasonable namespace.
Consensus: Approved with modification to @Unstable()
, but defer implementation until at least documentation generation support available on the compiler.
Proposal: #405
Discussion:
- Previous consensus: Approve as is.
- Revisiting due to comment from @bettinaheim.
- Having both
XAsY
andYAsX
directions more important than slight redundancy.
Consensus: Previous consensus holds, approve as written.