prometeu-studio/discussion/workflow/decisions/DEC-0006-pbs-ignored-values-lowering-and-warning.md

id	ticket	title	status	created	accepted	agenda	plans	tags
DEC-0006	pbs-game-facing-asset-refs-and-call-result-discard	PBS Ignored Values Lowering and Warning Policy	accepted	2026-03-27	2026-03-27	AGD-0006	PLN-0007	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.