---
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.