Keyword true

true is documented here as a full reference entry: grammatical role, semantics, canonical form, valid example, counter-example, diagnostics, interactions, and design notes.

Visual portrait of keyword true
Syntax portrait: a code vignette centered on true.

Visual anchor: each page now has its own wiki-style profile image. It shows a small code excerpt where true appears in its most recognizable form.

Quick navigation: use the previous, summary, and next links to move through the full keyword series without manually returning to the index.

Summary

Overview

FieldValue
Keywordtrue
FamilyLiteral
Suggested levelBeginner
Main neighborfalse
Short roletrue is a boolean literal keyword used to express a truth value directly in code.
Main effecttrue injects a truth value directly into execution and simplifies the reading of guards and returns.

The keyword true expresses a boolean truth directly. It matters because it avoids implicit conventions and keeps the decision visible in the source code.

A useful encyclopedic reading should answer three questions: where can true appear, what does it change in the block contract, and how does the compiler signal misuse?

Definition

true is a boolean literal keyword used to express a truth value directly in code.

The keyword true expresses a boolean truth directly. It matters because it avoids implicit conventions and keeps the decision visible in the source code.

Grammatical role

Provides the boolean true value.

This grammatical role is essential: if a reader understands the structural place of true, they already understand much of the diagnostics that will appear when it is moved or truncated.

Canonical syntax

Canonical form: `give true`.

The canonical form matters because it gives the compiler and the reader the same reference structure. A large share of diagnostics related to true come from an abbreviated, displaced, or incomplete form.

Detailed semantics

Semantically, true carries an immediate and unambiguous meaning. It introduces no extra computation; it directly fixes the logical state expected by the branch, guard, or return value.

In an encyclopedic reading, true should not be reduced to a dictionary definition. Its effect on scope, block shape, value visibility, control progression, and the diagnostic family it activates when misused must also be considered.

Effect on execution

true injects a truth value directly into execution and simplifies the reading of guards and returns.

In other words, the presence of true is not merely syntactic: it helps the reader predict what will be executed, produced, exposed, or forbidden from this point in the program.

Valid variants

  • `give true`.

These variants are not free synonyms. They indicate the legitimate forms from which one can reason about diagnostics, scope differences, or contract readability.

Vitte example

proc flag() -> bool {
  give true
}

This example shows true in a nominal context. It should be read globally: where the contract begins, which values are constrained, which output becomes observable, and why the presence of the keyword is justified.

Guided reading of the example

  1. First locate the full construction that contains true, not the isolated word.
  2. Then identify which contract becomes visible because of true: type, branch, binding, module, exit, or advanced boundary.
  3. Finish by checking the observable effect produced by the construction that contains true.

This guided reading is intentionally closer to a reference page than to a tutorial: it helps reconstruct the exact role of true in a complete block.

Comparison with C

int flag(void) {
  return 1;
}

This C comparison is structural: it aligns the role of the keyword with a familiar surface without claiming that the two languages carry exactly the same contracts.

The source of truth remains Vitte grammar and semantics. The comparison with C should be read as a cultural marker, not as a parallel specification.

Recommended uses

true deserves to appear when it simplifies the reading of the block's global contract, not when it merely adds one more surface form.

When to use it

  • When true makes the block contract more explicit at first reading.
  • When it reduces the number of implicit assumptions the reader must reconstruct mentally.
  • When a branch, guard, or return must carry a boolean truth without hidden convention.

When to avoid it

  • Avoid true when another, more precise keyword already carries the block's intent.
  • Avoid true when it adds only surface noise without clarifying the contract.
  • Avoid reading or teaching it as an isolated token with no relation to the full structure.

Common pitfalls

  • Using true in a grammatical layer where it does not belong.
  • Confusing the role of the keyword with the role of the full surrounding block.
  • Showing only the nominal form and never how the contract fails.

Invalid example and diagnostic

proc bad_flag() -> bool {
  give false
}

The literal is used to express a boolean result; the invalid variant mixes the wrong surface.

The counter-example is not merely wrong: it is wrong in an instructive way. It shows which grammar or execution-contract assumption is no longer accepted when true is moved, truncated, or combined with the wrong context. Concretely, the literal value used is not coherent with the expected boolean contract.

A good encyclopedic counter-example does not show arbitrarily broken code: it isolates the precise reason why true can no longer support the expected contract. Its teaching value is diagnostic before it is syntactic.

Common compilation errors

Typical messageUsual causeFix
unexpected token near trueThe keyword appears in an invalid form or grammatical layer.Return to the canonical form and verify placement and delimiters.
type mismatchThe keyword participates in a block whose value contract is incoherent.Realign the surrounding types, branches, or produced values.
invalid constructThe keyword is present but the surrounding construction is incomplete.Restore the missing branch, declarative part, or operands.

This table does not replace the compiler's exact diagnostics. It serves as a mental map: when true fails, the problem usually comes from an invalid grammatical form, an incoherent type contract, or an incomplete construction.

Neighbor keywords

KeywordOperational difference
falseDirect neighboring keyword: it helps explain what true does, either by contrast or by complement.

Comparison with neighboring keywords is essential on a wiki-style page: true is better understood when one knows precisely what it does not do.

Common misreadings

  • Reducing true to a local token instead of reading it as part of a full construction.
  • Explaining only the syntax and forgetting the reading or diagnostic contract it imposes.

Implementation and diagnostic notes

  • A useful diagnostic for this keyword should always connect the observed syntax to the expected contract.
  • From the compiler's point of view, this keyword should remain identifiable early enough to produce coherent, localized messages.

Presence in the book

See also