prometeu-studio/docs/pbs/decisions/Lifetime Control and Future Profiles Decision.md

Lifetime Control and Future Profiles Decision

Status: Accepted 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/pbs/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.