YINI Specification RC 6 is now released

The YINI configuration format has reached Specification Release Candidate 6.

YINI is a configuration format designed to feel familiar if you like INI-style files, but designed to bring more explicit structure, clarity, useful data types, and predictable parsing rules to real-world configuration needs..

The short version:

@yini

^ App
name = "Example"
version = "1.0.0"
debug = false

^^ Server
host = "127.0.0.1"
port = 8080

^^ Features
enabled = [
    "auth",
    "logging",
    "metrics",
]

YINI tries to sit somewhere between classic INI, JSON, TOML, and YAML:

• More structured than traditional INI.
• Less punctuation-heavy than JSON.
• Indentation-insensitive unlike YAML.
• Explicit about parsing rules and validation behavior.

RC 6 is an important release because it tightens several parts of the language and moves the format closer to a stable 1.0 specification.

What changed in RC 6?

RC 6 includes a number of syntax and behavior updates. The main theme is the same as before:

Make the format clear for humans, but deterministic for parsers.

Here are some of the notable updates.

Clearer section markers

YINI uses section markers to define structure.

^ App
name = "MyApp"

^^ Server
host = "localhost"

^^^ TLS
enabled = true

The number of section markers defines the nesting level. This keeps hierarchy visible without relying on indentation.

The primary section marker is:

^

YINI also supports alternative section markers, but ^ remains the recommended default for most files and examples.

Strict and lenient mode behavior is more clearly defined

YINI has two parsing modes:

• Lenient mode — practical, forgiving, and intended as the default.
• Strict mode — validation-focused and intended for stricter tooling, CI checks, and production-sensitive configuration.

A file can declare its intended mode:

@yini strict

or:

@yini lenient

RC 6 clarifies how these declarations should behave when the file is parsed in a different mode.

The goal is to avoid silent surprises. If a file says it expects strict behavior, tools should not quietly treat that as “close enough” in a looser context.

Comment syntax is more consistent

YINI supports common comment styles:

# A line comment

// Another line comment

; A full-line comment

/*
    A block comment.
*/

RC 6 clarifies comment behavior, including that # is now consistently treated as a comment marker outside strings.

This also affects number syntax, because # is no longer used for hexadecimal numbers.

Hexadecimal numbers use clearer prefixes

Instead of using # for hexadecimal notation, YINI now uses clearer forms such as:

color = 0xffcc00
mask = hex:ffcc00

This avoids conflict with comment syntax and makes the language easier to scan.

Digit separators are also supported for readability:

maxSize = 1_000_000
flags = 0b1111_0000
id = 0x_ab_cd_12_34

String handling was simplified

RC 6 continues to refine string behavior.

YINI supports different string forms for different needs:

name = "Example"
path = R"C:\Users\marko\config"
message = C"Line one\nLine two"

The distinction between raw strings and classic escaped strings is important:

• Raw strings preserve backslashes.
• Classic strings interpret escape sequences.

Triple-quoted strings are also available for longer text.

description = """
This is a longer string.
It can span multiple lines.
"""

The goal is to make string behavior explicit instead of surprising.

String concatenation is stricter and more predictable

String concatenation uses +, but RC 6 makes the rules more explicit.

In strict mode, concatenation is intentionally conservative:

title = "YINI " + "Config"

All operands must be string literals.

In lenient mode, scalar values may be allowed after the first string literal:

message = "Port: " + 8080

Result:

Port: 8080

But this is still string concatenation only. It is not arithmetic.

value = 1 + 2

That should not be treated as numeric addition.

This is one of the places where YINI deliberately favors predictability over cleverness.

Inline objects are more clearly specified

YINI supports inline objects for compact structured values:

database = {
    host: "localhost",
    port: 5432,
    ssl: true,
}

RC 6 clarifies the preferred object member syntax.

The canonical form is:

key: value

Lenient parsers may accept key = value in inline objects, but strict mode should require :.

That gives users a friendly mode while still keeping strict mode suitable for validation.

Lists remain bracketed and explicit

Lists use brackets:

plugins = [
    "auth",
    "cache",
    "metrics",
]

Trailing commas are convenient in hand-edited files and may be accepted in lenient mode.

Strict mode can reject them if the specification requires stricter validation.

Missing entries are not silently treated as null. This is intentional. YINI should not guess structure that was not written.

Duplicate keys and sections are safer

RC 6 keeps duplicate handling conservative.

Duplicate keys in the same section and nesting level are not silently overwritten.

In lenient mode, the first definition wins and later duplicates should produce a warning.

In strict mode, duplicates are errors.

This avoids one of the most frustrating configuration-file problems: a value being accidentally overridden far below the original definition.

Duplicate sections are also not treated as implicit merges. YINI avoids hidden merge behavior because it can become hard to reason about in larger files.

Strict files can use a .strict.yini suffix

RC 6 also documents the recommended naming convention for strict-mode YINI files:

config.strict.yini

This is not meant to replace the actual parser mode, but it gives humans and tools a useful signal.

For example, a CI workflow or editor extension can warn if a file looks like it should be strict but is being parsed differently.

The YINI ecosystem is growing too

Alongside the specification, there are now several related tools and repositories around the format.

The main pieces include:

• The YINI specification.
• A TypeScript parser.
• A Python parser.
• A CLI tool for parsing and converting YINI.
• Syntax highlighting support for editors using TextMate-style grammars.
• A public yini-test test suite for parser behavior and compatibility checks.
• The YINI homepage and documentation.

The yini-test repository is especially important because it gives parser implementations a shared set of cases to validate against. This helps keep behavior consistent across languages instead of each parser drifting in its own direction.

The CLI is useful for trying YINI quickly:

npx yini-cli parse config.yini

The TypeScript parser can be used directly in Node.js or TypeScript projects, and the Python parser is also being developed for Python-based tooling and applications.

Why RC 6 matters

RC 6 is not about adding flashy features.

It is mostly about tightening the language:

• Fewer ambiguous rules.
• Clearer strict vs lenient behavior.
• Safer duplicate handling.
• More explicit string behavior.
• Clearer number syntax.
• Better parser consistency.
• And stronger alignment between the specification and tooling.

That is the kind of work a configuration format needs before calling itself stable.

A config format should be boring in the right ways. It should be easy to read, hard to misread, and predictable for tools.

That is the direction YINI is aiming for.

Try it

A minimal YINI file looks like this:

@yini

^ App
name = "Hello YINI"
debug = false

^^ Server
host = "127.0.0.1"
port = 8080

Parse it with the CLI:

npx yini-cli parse config.yini

The result is structured data that can be exported as JSON or used by tools and applications.

Links

• YINI homepage: https://yini-lang.org
• YINI on GitHub: https://github.com/YINI-lang
• Specification: https://yini-lang.org/specification
• CLI tool: https://yini-lang.org/tools/yini-cli
• TypeScript parser: https://yini-lang.org/tools/yini-parser-ts
• Python parser: https://yini-lang.org/tools/yini-parser-python

Feedback welcome

RC 6 is a release-candidate specification, so feedback is still useful.

Especially helpful feedback includes:

• Confusing syntax rules.
• Parser edge cases.
• Unclear examples.
• Places where strict and lenient behavior should be clearer.
• Documentation gaps.
• And real-world configuration examples that would be useful to test against.

If you try YINI, find a rough edge, or have opinions about configuration formats, I would be happy to hear them.