Struct names are conventionally capitalized and their constructors are ordinary function bindings (#197). A user-defined fn with a capitalized name can therefore collide with — or masquerade as — a constructor. Found while reviewing #197:
fn Point(x) { "the function" }
struct Point { x: Int }
print(Point("str")); // "the function"
print(Point(1)); // Point {x: 1}
This is silently accepted (the two become type-dispatched overloads), while the reverse order — struct Point first, then fn Point(x) — errors with Illegal redefinition of function 'Point' with 1 parameter.
Proposal
Emit an analyser warning when a user-defined fn (named or via let) has a name starting with a capital letter, steering capitalized names toward struct constructors. Struct constructors themselves are of course exempt.
Open questions
- The language has no warning channel yet — analysis errors are fatal. Does this need warning infrastructure first (also useful elsewhere, e.g. unused variables), or should this specific case be an error?
- Should the asymmetry above also be fixed, so
fn + struct collisions are rejected consistently in both orders?
🤖
Struct names are conventionally capitalized and their constructors are ordinary function bindings (#197). A user-defined
fnwith a capitalized name can therefore collide with — or masquerade as — a constructor. Found while reviewing #197:This is silently accepted (the two become type-dispatched overloads), while the reverse order —
struct Pointfirst, thenfn Point(x)— errors withIllegal redefinition of function 'Point' with 1 parameter.Proposal
Emit an analyser warning when a user-defined
fn(named or vialet) has a name starting with a capital letter, steering capitalized names toward struct constructors. Struct constructors themselves are of course exempt.Open questions
fn+structcollisions are rejected consistently in both orders?🤖