Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[P2] Parser: optional computed class fields are rejected

Open Beginner friendly
  • Is something wrong?
#2,765 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp, typescript
Domain
backend, compilers

Research direction

Read Parser.Classes.cs::ParseComputedClassMember and compare its handling of computed keys with the ordinary identifier-keyed optional field path. Add coverage for optional computed fields in both class declarations and class expressions, using the provided minimal examples; run the checked interpreter and standalone compiler commands. Done means both sources parse and preserve optional field information while the existing initialized computed field controls still pass.

Written by the indexing model from the issue text.

Description

bug priority: P2

Valid optional computed class fields are rejected before checking or execution, even with a plain string literal key and no generic or Symbol types.

class C { ["field"]?: number; }
const instance: any = new C();
console.log(instance.field === undefined);

Strict TypeScript 6.0.3 accepts the exact source. Node 22.23.2 prints true and exits 0. Both the checked SharpTS interpreter and standalone compiler reject line 1, exit 1:

Expect ';' after computed property field declaration.

The class-expression equivalent also rejects before checking:

const C = class { ["field"]?: number; };
console.log(typeof C);

Node prints function, strict TypeScript accepts, and both SharpTS CLI modes fail with the same parser diagnostic. These reductions do not depend on inferred Symbol-key legality, runtime field lookup, generics, accessors, or member ordering.

Passing controls on the same immutable runtime:

  • Ordinary optional field class C { field?: number; } is accepted and console.log(typeof C) prints function in Node, checked interpretation, and the isolated saved program.
  • Initialized computed literal field class C { ["field"] = 1; } is accepted and its value is 1 in all three executions.
  • Initialized computed identifier string field is also accepted and returns 1.

The compiled positive controls passed full IL verification before execution, referenced only eight System.* assemblies, and ran without any adjacent SharpTS.dll. The failing optional sources emitted no assembly and were not executed as saved output.

Source lead: Parser.Classes.cs::ParseComputedClassMember consumes ], then optionally : and =, but never the optional ? token. It creates the computed Stmt.Field with IsOptional: false. Both declaration and expression class-body paths use this helper. The ordinary identifier-keyed paths already consume ? and retain optional metadata. Accepting this syntax should retain the field's type/optional information and existing field initialization rules.

Commands:

node D:/SharpTS/external/typescript/lib/tsc.js --ignoreConfig --strict --target ES2022 --skipLibCheck --noEmit SOURCE.ts
node --experimental-strip-types --disable-warning=ExperimentalWarning SOURCE.ts
dotnet PIN/SharpTS.dll --no-tsconfig --noLib SOURCE.ts
dotnet PIN/SharpTS.dll --no-tsconfig --noLib --compile SOURCE.ts -o OUTPUT.dll --standalone --verify

Provenance: copied pre-#2675 CLI at source HEAD 585f115288389f08688eb4bd6f56f887a247f6ab. SHA256 C41F08FE5B899BE348C84B2AB12AFA3521C7CDD23D1FCF6FA2FA2D2A2478239D is unchanged before/after both proof runs. Exact declaration source SHA256 FB81FC778A89E24404E1F76D26C6BC4D9F107E127767F25DD71C8C33DC37CEBD; expression source SHA256 8B8ACFA58423D8D9C7F3F4AC7A64C796948F1876CDC6D0F627497BF4C61E5045. No introducing commit is established.

Ten fresh all-state searches plus full closest-owner bodies/comments were read. Open #2713 owns the separate declare/computed-name prohibition; #2736 is a checker circular-type false positive after parsing; #2446 owns inferred const Symbol key rejection; #2508 owns missing computed-literal fields in checked member types. Closed #34/#37 concern bare JavaScript fields, and #121/#2338 concern index signatures. None owns the optional computed ? parse failure above. Found during #2675 test-boundary review; do not expand that runtime key-order fix.

Evidence is retained under ignored artifacts/p2-goal/2675-computed-field-owner-audit/: exact sources, results.json, additional-results.json, stdout/stderr, full-verified/System-only positive outputs, fresh searches, and related issue bodies. No project build or tracked source/test edit was made for this audit.

Dominant language
C#
Stars
156
Forks
4
Avg merge
4h 52m
Merged PRs (30d)
45

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nickna/SharpTS

All issues in nickna/SharpTS

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.