Features Reference

A feature is a CCL language capability that every conformant implementation must handle identically. Features describe what the language is — no reasonable implementation can legitimately reject one.

Compare with behaviors, which encode real implementation choices (mutually exclusive pairs), and variants, which are spec-compliance profiles.

Each heading below is the canonical anchor for the corresponding feature:* tag in the test suite.

comments

Tag: feature:comments

Lines beginning with /= are comments. Comments are parsed as entries with the special key /; filter strips them from processing.

/= this is a comment
key = value

See Getting Started — Comments.

empty_keys

Tag: feature:empty_keys

Entries of the form = value have an empty key. During build_hierarchy, sibling empty-key entries form an array (the canonical “bare list” shape).

items =
  = first
  = second

See Bare List Hierarchy Representation.

multiline_continuation

Tag: feature:multiline_continuation

Indented lines continue the value of the preceding entry. The baseline N that separates “new entry” from “continuation” depends on context; see Continuation Lines for the full algorithm.

description =
  This value
  spans multiple lines.

multiline_keys

Tag: feature:multiline_keys

Keys may span multiple lines. Less common than multiline values but permitted by the grammar.

unicode

Tag: feature:unicode

Keys and values may contain arbitrary UTF-8. Implementations must not mangle or reject non-ASCII content.

greeting = こんにちは
emoji = 🎉

whitespace

Tag: feature:whitespace

Internal whitespace in values is preserved. Key whitespace is trimmed; value whitespace is trimmed only at the boundary immediately after = and before the line terminator.

tab_in_value_preserved

Tag: feature:tab_in_value_preserved

Tabs appearing inside a value (between non-whitespace content) are preserved verbatim. Boundary tabs immediately after = are trimmed — this is the universal default and is intentionally untagged. Separate from the Tab Handling behavior, which governs leading tabs on continuation lines.

toplevel_indent_strip

Tag: feature:toplevel_indent_strip

Top-level keys have any leading whitespace stripped (OCaml String.trim) before the baseline-N rule is applied. This is what lets parse use N = 0 at the top level without top-level keys accidentally registering as continuations.

This feature is paired with the toplevel_indent_strip vs toplevel_indent_preserve behavior group — the feature tag marks tests that exercise the stripping rule under the reference-compliant behavior choice.

optional_typed_accessors

Tag: feature:optional_typed_accessors

Marks tests whose intent is to exercise the typed access functions (get_string, get_int, get_bool, get_float, get_list). Typed accessors are optional — an implementation may expose only raw string values and still be conformant on every other axis.

This tag is partly redundant with the test’s functions capability list (a test that validates get_int will already be filtered out for implementations without get_int). It remains useful as intent documentation: scanning a test’s tags tells a reader “this test is fundamentally about typed access” rather than forcing them to infer that from the validation list.

experimental_dotted_keys

Tag: feature:experimental_dotted_keys

Dotted keys (database.host = localhost) are treated as literal strings by default in CCL. The experimental_dotted_keys feature covers opt-in behavior via expand_dotted that rewrites them into nested structures.

See Dotted Keys Explained for the literal-vs-hierarchical distinction.