Naming convention violation

Why this fires¶

Zolo enforces conventional casing so that names communicate their kind at a glance. The compiler classifies identifiers in two buckets:

Libraries can choose accepted names for free functions returning their nominal type with @naming(returns: [.SnakeCase, .PascalCase]). Inferred returns, imported aliases, and re-exports preserve the policy. The lint still rejects other styles. Methods keep their ordinary convention, and an unrelated type named Node keeps the default. Existing View component naming remains supported.

@naming(returns: [.SnakeCase, .PascalCase])
pub struct Node { text: str }
fn Greeting() { Node.new(text: "Hello") } // valid PascalCase
fn build_node() { Node.new(text: "Hello") } // valid snake_case
fn buildNode() { Node.new(text: "Hello") } // warning: use snake_case or PascalCase

fn ParseInput(s: str) { }   // warning: function name should be snake_case
struct http_request { }     // warning: struct name should be PascalCase

Fix it¶

Rename the binding to follow the convention. Editor refactors handle most cases:

fn parse_input(s: str) { }
struct HttpRequest { }

Names with acronyms¶

Treat acronyms as words — HttpRequest, not HTTPRequest; parse_html, not parse_HTML. This keeps boundary detection unambiguous for tooling and humans alike.

When the lint is wrong¶

If you are interfacing with an external system whose names you must match exactly (FFI, a JSON schema you can't control), suppress the lint locally rather than renaming:

@diagnostic(off, "naming-convention")
extern fn JNI_OnLoad(vm: *VM) -> int

For most code, fix the name.