122 lines
4.5 KiB
Markdown
122 lines
4.5 KiB
Markdown
# Lifetime Control and Future Profiles Decision
|
|
|
|
Status: Accepted (Implemented)
|
|
Cycle: Initial lifetime-control policy closure pass
|
|
|
|
## 1. Context
|
|
|
|
PBS v1 no longer uses the old RC/HIP model as an active core-language direction.
|
|
|
|
The remaining question is not how to design explicit lifetime control now, but how the project should treat legacy concepts and what policy should govern any future reintroduction of lifetime-oriented language features.
|
|
|
|
## 2. Decision
|
|
|
|
PBS v1 adopts the following lifetime-control policy baseline:
|
|
|
|
1. No lifetime-control keyword is reserved in core PBS merely for possible future use.
|
|
2. If a lifetime-control surface is not active in v1, it should not remain in the language as a reserved future-only keyword on that basis alone.
|
|
3. Advanced memory workflows should default to library/tooling-first exploration rather than syntax-first activation.
|
|
4. GC remains the default core model; future explicit lifetime control, if ever introduced, must be profile-gated rather than silently folded into the default language.
|
|
5. Future lifetime-oriented syntax may be introduced only when there is concrete evidence that library/tooling approaches are insufficient.
|
|
|
|
## 3. Legacy RC/HIP Concepts
|
|
|
|
Legacy concepts such as:
|
|
|
|
- `alloc`
|
|
- `borrow`
|
|
- `take`
|
|
- `weak`
|
|
- pool-style and arena-style control patterns
|
|
- object reuse patterns
|
|
|
|
do not remain active merely by historical inertia.
|
|
|
|
For PBS v1 policy:
|
|
|
|
- legacy concepts may survive as historical or design-reference material,
|
|
- but they do not imply reserved syntax commitment,
|
|
- and they do not imply a roadmap promise of later activation.
|
|
|
|
## 4. Language Versus Library Boundary
|
|
|
|
The default policy is:
|
|
|
|
- library first,
|
|
- tooling first,
|
|
- profile later only if justified,
|
|
- syntax last.
|
|
|
|
This means advanced workflows should first be explored through:
|
|
|
|
- stdlib APIs,
|
|
- tooling support,
|
|
- diagnostics,
|
|
- profiling guidance,
|
|
- subsystem-specific contracts where needed.
|
|
|
|
The language should not absorb explicit lifetime syntax simply because a legacy concept existed before.
|
|
|
|
## 5. Migration Narrative
|
|
|
|
The official migration narrative is:
|
|
|
|
- PBS v1 moves away from RC/HIP-style user-authored lifetime control as the core user model,
|
|
- GC plus deterministic execution is the baseline,
|
|
- performance-sensitive reasoning remains important,
|
|
- but performance and memory control should rise through explicit APIs and tooling before new syntax is considered.
|
|
|
|
This is a deliberate simplification, not a temporary placeholder awaiting automatic return to explicit ownership syntax.
|
|
|
|
## 6. Future Activation Criteria
|
|
|
|
Any future lifetime-oriented language/profile work must satisfy all of the following:
|
|
|
|
1. Real implementation and product evidence shows that library/tooling-first approaches are insufficient.
|
|
2. The proposed feature has a coherent semantic model that does not break the GC baseline by accident.
|
|
3. The feature can be isolated behind an explicit profile or equivalent opt-in boundary.
|
|
4. Diagnostics, conformance, and migration obligations are clear.
|
|
5. The feature does not degrade the beginner-facing default language without strong justification.
|
|
|
|
Future activation must be justified by present need and validated design, not by preserving speculative syntax in the current language.
|
|
|
|
## 7. Invariants
|
|
|
|
- GC remains the default core runtime model.
|
|
- Core PBS v1 does not promise future activation of legacy lifetime syntax.
|
|
- Absence of reserved lifetime keywords is a deliberate policy choice.
|
|
- Future explicit control must be explicit, justified, and profile-gated.
|
|
|
|
## 8. Beginner-Facing Model
|
|
|
|
The user-facing explanation should be:
|
|
|
|
- PBS v1 does not require ownership or lifetime syntax in ordinary code,
|
|
- advanced control is not removed as a future possibility,
|
|
- but it will be introduced only if it proves necessary and only through explicit design, not through dormant keywords left in the language.
|
|
|
|
## 9. Explicit Non-Decisions
|
|
|
|
This decision record does not yet close:
|
|
|
|
- the exact shape of any future profile mechanism,
|
|
- the exact syntax of any future explicit lifetime feature,
|
|
- the future stdlib design for pools, arenas, or weak-reference-like patterns.
|
|
|
|
## 10. Spec Impact
|
|
|
|
This decision should feed at least:
|
|
|
|
- `docs/pbs/specs/10. Memory and Lifetime Specification.md`
|
|
- `docs/general/specs/17. Compatibility and Evolution Policy.md`
|
|
- `docs/pbs/specs/3. Core Syntax Specification.md`
|
|
|
|
## 11. Validation Notes
|
|
|
|
The intended policy is:
|
|
|
|
- no dormant lifetime keywords in core v1,
|
|
- no nostalgia-based reservation policy,
|
|
- library/tooling first,
|
|
- profile-gated language activation only when clearly justified.
|