Keyword string

Definition

string is a built-in type keyword used to make a value contract explicit.

The keyword string makes a value contract explicit in a signature, local declaration, or data structure. Its main role is not decorative: it bounds what the compiler and the reader may expect from an expression.

Grammatical role

Specifies the language's text type.

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

Canonical syntax

Canonical form: `let name: string = "demo"`.

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

Detailed semantics

Semantically, string is not just a type name: it constrains operation compatibility, assignment validity, and return shapes. As soon as it appears, the reader should check which operations become legal and which conversions become forbidden.

In an encyclopedic reading, string 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

string does not directly modify control flow; it restricts what the program may legally produce, consume, or transform.

In other words, the presence of string 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

• `let name: string = "demo"`.

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 greet(name: string) -> string {
  give "hello, " + name
}

This example shows string 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 string, not the isolated word.
2. Then identify which contract becomes visible because of string: type, branch, binding, module, exit, or advanced boundary.
3. Finish by checking the observable effect produced by the construction that contains string.

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

Comparison with C

const char* greet(const char* name) {
  return name;
}

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

string 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 string makes the block contract more explicit at first reading.
• When it reduces the number of implicit assumptions the reader must reconstruct mentally.
• When a signature must state the nature of the manipulated data clearly.

When to avoid it

• Avoid string when another, more precise keyword already carries the block's intent.
• Avoid string 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 string 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_string() -> string {
  let name: string = 12
  give name
}

The textual contract is broken because the declaration receives a numeric value.

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 string is moved, truncated, or combined with the wrong context. Concretely, the textual contract breaks because a numeric value is injected into a textual declaration.

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

Common compilation errors

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

Neighbor keywords

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

Common misreadings

• Reducing string 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

• docs/book/chapters/05-types.html
• docs/book/chapters/17-stdlib.html
• docs/book/chapters/27-grammar.html

See also

• docs/book/chapters/keywords/erreurs-compilateur.html
• docs/book/chapters/keywords/int.html
• docs/book/glossary.html