89 lines
3.6 KiB
Markdown
89 lines
3.6 KiB
Markdown
---
|
|
id: DEC-0006
|
|
ticket: pbs-game-facing-asset-refs-and-call-result-discard
|
|
title: PBS Ignored Values Lowering and Warning Policy
|
|
status: accepted
|
|
created: 2026-03-27
|
|
accepted: 2026-03-27
|
|
agenda: AGD-0006
|
|
plans: [PLN-0007]
|
|
tags: [compiler, pbs, ergonomics, lowering, diagnostics, expression-statements, warnings]
|
|
---
|
|
|
|
## Context
|
|
|
|
PBS ainda precisava fixar o comportamento de `expression statements` cujo valor produzido não é consumido.
|
|
|
|
Sem essa decisão, a disciplina de stack do backend continua vazando para a surface do autor:
|
|
|
|
- alguns callsites com retorno materializado ficam semanticamente ambíguos;
|
|
- a política de descarte pode ficar implícita demais ou inconsistente entre passes;
|
|
- o usuário não recebe feedback claro quando ignora um valor que a linguagem materializou.
|
|
|
|
Essa discussão não exige uma exceção por API específica.
|
|
Ela exige uma regra geral de linguagem com lowering e diagnóstico previsíveis.
|
|
|
|
## Decision
|
|
|
|
PBS SHALL adotar uma regra geral para ignored values em `expression statement`.
|
|
|
|
Quando uma expressão usada como statement produzir um valor materializado que não seja consumido, o compiler SHALL:
|
|
|
|
1. lowerar explicitamente o descarte desse valor;
|
|
2. emitir um warning na v1.
|
|
|
|
Essa política SHALL ser geral, e não uma exceção localizada para certos callsites ou certas superfícies de API.
|
|
|
|
O warning inicial SHALL existir como baseline diagnóstica da linguagem.
|
|
Refinamentos futuros de severidade, suppressions ou subcategorias MAY acontecer depois, mas não bloqueiam esta decisão.
|
|
|
|
## Rationale
|
|
|
|
Essa regra resolve a tensão principal da agenda:
|
|
|
|
- a autoria continua simples, porque o usuário pode escrever uma expressão como statement;
|
|
- o protocolo executável continua explícito, porque o compiler assume o descarte;
|
|
- a linguagem continua honesta, porque o usuário recebe um warning quando ignora um valor material.
|
|
|
|
Isso é superior a duas alternativas piores:
|
|
|
|
- exigir consumo explícito de todo valor sempre, empurrando ruído operacional para o source;
|
|
- ou descartar silenciosamente tudo, removendo feedback útil em situações potencialmente equivocadas.
|
|
|
|
## Technical Specification
|
|
|
|
### 1. General Rule
|
|
|
|
- Any PBS `expression statement` that produces a materialized value and does not consume it SHALL trigger ignored-value handling.
|
|
- Ignored-value handling SHALL consist of:
|
|
- explicit lowering for value discard;
|
|
- a warning diagnostic.
|
|
|
|
### 2. Scope
|
|
|
|
- The rule SHALL apply generally across expression statements.
|
|
- The rule MUST NOT be restricted to asset-facing APIs, host-backed calls, or any single subsystem.
|
|
- The rule MAY apply equally to pure or impure expressions if the language surface materializes a value that is then ignored.
|
|
|
|
### 3. Lowering Ownership
|
|
|
|
- The compiler backend SHALL remain responsible for the executable lowering that discards the value.
|
|
- Frontend diagnostics MAY identify the situation earlier if architecture permits, but the normative executable behavior remains compiler-owned.
|
|
|
|
### 4. Diagnostic Policy
|
|
|
|
- The baseline v1 diagnostic level SHALL be warning.
|
|
- Future work MAY define suppression mechanisms, lint categories, escalation rules, or context-sensitive exemptions.
|
|
- No such refinement is required to consider this decision accepted.
|
|
|
|
## Constraints
|
|
|
|
- PBS MUST keep the rule general and easy to explain.
|
|
- PBS MUST NOT depend on backend stack discipline leaking into source-level author decisions.
|
|
- PBS MUST NOT require API-by-API bespoke ignored-value semantics as the baseline language policy.
|
|
|
|
## Revision Log
|
|
|
|
- 2026-03-27: Initial accepted decision from AGD-0006.
|
|
- 2026-03-27: Locked ignored values as a general lowering rule with warning severity in v1.
|