req

What it means

req is one of the fourteen universal-core predicates (§55.1) — the validation vocabulary that comes built into every scrml type without import. Where is some checks for existence (an empty string IS some — it's a defined value), req checks for a meaningful value — an empty string is NOT meaningful.

The two predicates are deliberately distinct. A user's middle name might be the empty string (no middle name — still a defined answer); a user's first name probably shouldn't be. The first case wants is some; the second wants req.

Syntax

On a state cell declaration:

<firstName: string req> = ""
<quantity: number req> = 0

On a function parameter:

function greet(name: string req) { ... }

On a struct field:

type User:struct = {
  firstName: string req
  middleName: string is some  // empty middle name is OK
  lastName: string req
}

On a schema column:

<schema>
  users {
    id:    integer req
    email: string req
    bio:   string is some
  }
</schema>

Worked example

A signup form. The req on each cell makes the empty-string default fail validation, so the submit button stays disabled until the user fills both fields meaningfully.

<program>

  <email: string req>    = ""
  <password: string req> = ""

  <form>
    <input type="email"    bind:value=@email    placeholder="Email">
    <input type="password" bind:value=@password placeholder="Password">

    <errors of=@email/>
    <errors of=@password/>

    <button disabled=!@email.isValid || !@password.isValid>Sign up</button>
  </form>

</program>

Three things to notice:

• Validation is on the type, not on the input. The string req annotation is the schema. There is no separate Zod / Yup / Joi declaration to keep in sync.
• @email.isValid is auto-synthesised. Every cell with a validator surface gets an .isValid computed property for free (§55.5).
• <errors of=…/> renders the active failure messages. See <errors> for the full surface.

Semantics

req evaluates per the value's runtime type:

req applies to scalar leaf values per the table above. On a struct field, req fires on the field's value — not on the struct as a whole. The compound-cell validity surface (per §55.5) composes upward: a struct cell's .isValid is false iff ANY field's validators fail.

For enum-typed cells holding a defined variant, the cell carries a tag — bare-variant req on an enum cell is trivially satisfied once a variant is present.

Edge cases

Zero is not absence

For a field like temperature: number req, an honest reading of zero (e.g., 0°C in a weather widget) will fail req. If zero is meaningful in your domain, use is some instead, or constrain with a refinement predicate like number(>=-100 && <=200).

req does not imply existence

A cell holding scrml's absence value (not) also fails req. Per §55.12 short-circuit semantics, both "" and not produce the same .Required error tag — downstream validators are skipped. The sibling .NotSome tag is reserved for is some failures.

req on derived cells fires E-DERIVED-WITH-VALIDATORS

Validators apply to inputs, never to derived outputs. Trying to put req on a derived cell is a compile error — see E-DERIVED-WITH-VALIDATORS .

Related

• is some — the existence-only sibling. "" IS some; "" fails req.
• not — absence predicate. Both null and undefined from other languages collapse onto not in scrml.
• <errors of=…/> — renders the validity surface req participates in.
• <schema> — req on a schema column emits SQL NOT NULL + a CHECK constraint matching the per-type emptiness rule.
• Learn: Validators — tutorial on the full validity surface.

Specification

Normative text: SPEC §55.1 (universal-core predicate catalog) + §42.2.5 (req vs is some — distinct predicates) + §55.5 (validity-surface synthesis & .isValid) + §55.12 (req / is some short-circuit) + §55.14 (derived + validators forbidden). The req-on-derived error is §34 row E-DERIVED-WITH-VALIDATORS. Spec lives at compiler/SPEC.md .