[EP] Support dash in identifier?

[He1pa]

Enhancement

do we need to support dash in identifier?

e.g.,

api-Version = "apps/v1"

[He1pa]

related issue: #1787

[tvandinther]

I support this if modules are also updated to support dashes for consistency. Otherwise we have a situation where my-app = {} is valid but import .my-app and my-app.Schema{} is not.

I personally think that the semantic distinction between fields and identifiers is enough to explain the issue in #1787. Wrapping the top level in {} to turn it into a single dict export to allow string-literals as fields makes sense.

My motivation for semi-supporting the change is to align module naming with that of file/directory naming and by extension, that would include supporting the dash in identifiers.

[sealor]

I like that idea too. It would also make KCL more similar to its YAML output.

[Peefy]

Agreed this is worth pursuing — dash-keys are pervasive in K8s manifests and the current ["api-Version"] escape hatch (see #1787) is noisy at the top level.

The design constraint to settle first is consistency across the whole name grammar, not just assignment keys:

1. Config keys — the easy case; api-Version = "apps/v1" only needs the lexer/identifier grammar to accept - after the first character.
2. Schema attributes — needs a decision on whether schema Deployment: api-Version: str is allowed bare or still requires quoted attribute names.
3. Module/pkg paths — as noted above, import .my-app and my-app.Schema{} currently cannot work: pkgpath segments are dot-separated and the import grammar has no notion of a dash. Allowing dashes in identifiers but not in module references creates the asymmetry tvandinther described.

My suggestion would be to phase it: land (1) first since it is self-contained and unblocks the K8s use case, then treat (2) and (3) as follow-ups with a KEP covering the pkgpath grammar extension (import .my-app resolving to a quoted directory name).

Adding the lang-design label to track the spec discussion.