128 lines
3.9 KiB
Markdown
128 lines
3.9 KiB
Markdown
# PBS Diagnostics Workshop 3
|
|
|
|
Status: Active
|
|
|
|
## Purpose
|
|
|
|
Run the third focused discussion for `11. Diagnostics Specification.md` on warnings and cost-facing diagnostics:
|
|
|
|
- whether warnings are part of the normative contract,
|
|
- which qualitative cost facts deserve mandatory surfacing,
|
|
- and where diagnostics stops and profiling begins.
|
|
|
|
## Why This Slice Third
|
|
|
|
This slice should come after identity and wording because warning policy is only meaningful once the baseline diagnostic surface is already stable.
|
|
|
|
It should also stay qualitative and avoid turning performance metrics into language law.
|
|
|
|
## Proposed Meeting Order
|
|
|
|
1. Reconfirm the cost facts already fixed by memory and lifetime rules.
|
|
2. Decide whether warnings are in or out of conformance.
|
|
3. Decide whether any qualitative cost diagnostics are mandatory.
|
|
4. Decide the boundary between diagnostics, linting, and profiling.
|
|
5. Record backend-mapping implications for Workshop 4.
|
|
|
|
## Already-Settled Inputs To Reconfirm
|
|
|
|
The meeting should explicitly reaffirm:
|
|
|
|
- retention-bearing `bind` is a normatively relevant cost fact,
|
|
- host-boundary crossings are normatively relevant cost facts,
|
|
- copy-versus-alias behavior is normatively relevant qualitatively,
|
|
- and exact byte counts or performance rankings are not normative.
|
|
|
|
## Decisions To Produce
|
|
|
|
1. Whether warnings are part of v1 conformance.
|
|
2. Whether any qualitative cost diagnostics are mandatory.
|
|
3. The line between core diagnostics and optional tooling enrichment.
|
|
4. Whether cost diagnostics belong in `11` alone or also in `13`.
|
|
|
|
## Candidate Decisions
|
|
|
|
### 1. Warnings Are Outside Minimum Conformance In v1
|
|
|
|
Candidate direction:
|
|
|
|
- conforming tools may emit warnings,
|
|
- but v1 does not require them for conformance.
|
|
|
|
Rationale:
|
|
|
|
- This keeps the baseline small.
|
|
- It avoids forcing one style of beginner guidance too early.
|
|
|
|
Alternative to discuss:
|
|
|
|
- require a very small mandatory warning set for high-value cost facts.
|
|
|
|
### 2. Cost Notes Are Encouraged But Optional
|
|
|
|
Candidate direction:
|
|
|
|
- tools may surface notes or warnings for:
|
|
retention-bearing `bind`,
|
|
host-boundary crossings,
|
|
and observable alias-versus-copy behavior.
|
|
- none of these are mandatory in v1 conformance.
|
|
|
|
Rationale:
|
|
|
|
- This respects the normative cost model without overcommitting on tooling policy.
|
|
|
|
### 3. Quantitative Performance Reporting Is Not Diagnostics Contract
|
|
|
|
Candidate direction:
|
|
|
|
- exact allocation counts,
|
|
- exact byte counts,
|
|
- and performance ranking remain outside the diagnostics spec.
|
|
|
|
Rationale:
|
|
|
|
- Those belong to profiling, not to language acceptance/rejection diagnostics.
|
|
|
|
### 4. Linting Remains Implementation-Defined
|
|
|
|
Candidate direction:
|
|
|
|
- style hints, performance nudges, and educational suggestions remain implementation-defined unless later promoted deliberately.
|
|
|
|
Rationale:
|
|
|
|
- This prevents `11` from becoming a general lint catalog.
|
|
|
|
## Questions To Resolve In The Room
|
|
|
|
1. Is there any warning that is valuable enough to make mandatory in v1?
|
|
2. Should cost diagnostics be notes only, warnings only, or fully tool-defined?
|
|
3. Do host-boundary warnings belong to diagnostics, SDK guidance, or both?
|
|
4. How should `13` treat optional warnings in conformance fixtures?
|
|
5. Does excluding warnings from conformance undermine the beginner-facing goals of PBS?
|
|
|
|
## Expected Outputs
|
|
|
|
This workshop should produce:
|
|
|
|
1. a decision record for warnings and conformance,
|
|
2. a decision record for cost diagnostics boundaries,
|
|
3. and follow-up notes for `13`.
|
|
|
|
## Explicit Deferrals For Workshop 4
|
|
|
|
- backend-originated error mapping,
|
|
- source maps,
|
|
- verifier/load-facing attribution,
|
|
- and artifact-tool diagnostics.
|
|
|
|
## Inputs
|
|
|
|
- `docs/pbs/specs/10. Memory and Lifetime Specification.md`
|
|
- `docs/pbs/specs/11. Diagnostics Specification.md`
|
|
- `docs/pbs/specs/13. Conformance Test Specification.md`
|
|
- `docs/pbs/agendas/11. Diagnostics Agenda.md`
|
|
- `docs/pbs/agendas/11.1. Diagnostics Workshop 1 - Diagnostic Identity and Attribution.md`
|
|
|