Limits

Package names on this page are preview naming and may change before launch.

Small, reviewable files

Every .ael file will have to meet two limits, and each one on its own:

• At most 5,000 bytes. That is 5,000 bytes as stored, not 5,000 characters.
• At most 5,000 lines.

A file of 5,000 bytes and 5,000 lines will pass; one byte or one line more will fail, whatever the other count is. The limits will apply to every source file: main.ael, pack.ael, metadata.ael, every component, every extension file, your tests and any source a tool generates for you.

How the limits count

• Bytes will be counted exactly as stored, before anything else happens: every space, tab and line break, every byte of a character outside ASCII, and every comment.
• A byte-order mark at the start of a file will count as three bytes.
• A carriage return followed by a line feed will be one line ending, and two bytes.
• A last line without a line ending will still count as a line. A line ending at the very end of the file will not add an empty line.
• An empty file will have zero lines.

The limits will apply to source only. Compiled files, package files and your finished program will not be limited by them, and a component together with its extension files may be larger than 5,000 bytes.

When a file grows

1. Move private helper functions into extension files beside the component: support.agent.extended.ael, then support.agent.extended.2.ael and up. See Files and roles.
2. Split a long function into helpers. A single function, including a component's primary, will have to fit in one file: a function will never start in one file and end in another.
3. Share what other components need as a global or reusable function in a file of its own. See Functions and visibility.

The formatter will never split a file or move code for you. If formatting would push a file over a limit, it will report that instead of writing the file. A limit failure will name the file, the limit it crossed and the counts it measured.

Extension files

• The unnumbered extension file will be the first; the next will be numbered 2. Numbers will be plain decimal, with no leading zeros.
• Numbers may have gaps, so removing one extension file will never force you to rename the others.
• A component will be able to have up to 1,023 extension files.

Names

• Names will be ASCII: letters, digits and _, not starting with a digit.
• A project name will be at most 64 characters.
• A package name will be lower case, slash-separated and at most 128 characters, such as server/http.

Values and capacities

• Integers will be at most 64 bits wide. The largest integer literal will be 18,446,744,073,709,551,615.
• The capacity N of Str<N> and Vec<T, N> will have to fit a u32, at most 4,294,967,295, and the target's largest object.
• A text literal will have to fit its type's capacity, or the check will fail.
• A full collection will return an error and stay unchanged; it will never grow past its capacity.

Not in the preview syntax

The preview leaves these out. Some will be described when the syntax is final; others are deliberate limits of Beta 0.0.1.

• Floating-point and fixed-point numbers, usize and isize.
• Hexadecimal, binary and exponent literals.
• Generic types and functions of your own, traits, closures and functions used as values.
• else if, break and continue; if and match as values.
• Building a struct by field names; pattern conditions; match on structs, text or lists.
• Indexing or slicing text.
• Returning a reference, moving one field out of a struct, or keeping a reference across a wait.
• Recursion whose depth cannot be bounded, on the smallest boards.
• The reserved words pub, task, tool, service, prompt, region, await, unsafe, extern and static.

Each limit will be there so that what you write can be checked completely, and so that the memory a program uses stays predictable.