Design records

A design record is written before a feature is finished, sometimes before a line of it is implemented. It works out the vocabulary, the trait shapes, the open questions and the gaps against the real checker, in the depth a single language page cannot carry. Every one of them opens with a status line - proposed, partly implemented, or done - so a reader knows how much of what follows exists yet.

What belongs here#

The specification of a feature that spans several packages or several language/ pages: collections, streams, concurrency, encoding, paths, URIs, linear algebra, entities and components, resources, the project file, the natives of std, destructors, the operating system, the VM, the sandbox of receiver scripts, the REPL, networking with TLS and HTTP, the Domain Name System, the first-party packages outside std for databases and other services, the web layer on top of the network, the language server, the debugger, the public release with its website and package registry, where a program may panic, cases with fixed values and bit flags, cases as types of a closed trait, YAML and regular expressions, random numbers, exact decimal numbers, named time zones, command lines, tensors and gradients, the application framework, the JavaScript and PHP back ends, and the brand: the logo, the colours, the type and how the toolchain colours its output. Each is plain Markdown without front matter, linked here rather than copied, and stays where the feature it describes keeps changing. The roadmap orders them into the milestones that are still ahead.

What does not belong here: the compiler's own implementation, which is in internals/; the settled rules of the language, which are in language/ once a feature has a page there; and the reasons behind a decision that no longer needs a whole record, which belong in explanation/.

Design documents#

• Streams
• Encoding
• Linear Algebra and Geometry
• Entities, Components and Scenes
• Concurrency and Parallelism
• Collections
• Natives: the Audit Table of the Manifest
• Collection Storage: ArrayList, the Hash Tables and the Tries on Buffer
• Loops as Expressions
• File Paths
• The Project File
• Resources
• Uniform Resource Identifiers
• Destructors, close() and using
• The Operating System
• The Bytecode VM
• Receiver Scripts and the Sandbox
• Script Receivers in project.trb
• Releasing TorbScript
• Networking, TLS and HTTP
• The Domain Name System
• First-Party Packages
• Binary Formats
• Web: Handlers, HTML and a Live UI
• The REPL
• The language server
• The Debugger
• Panics
• Cases with Fixed Values and Flags
• Closed Traits: Every Case Is a Type
• Deprecation
• YAML, Regular Expressions and Markdown
• Random Numbers
• Decimal Numbers
• Named Time Zones
• Command Lines
• Tensors, Gradients and the GPU
• Tensors on the CPU: std/tensor
• The Application Framework
• Language Models and Agents
• JavaScript and PHP Back Ends
• IR Bodies of Natives
• Foreign Functions
• The TorbScript Brand
• Roadmap