TS conformance: conditionalTypes1 remainder — mapped-type relations, DeepReadonly/readonly-mapped enforcement, generic assignment narrowing

[nickna]

Part of #226. After the conditional-relation round (deferred-conditional constraints, conditional↔conditional rule, distributivity flag), conditionalTypes1.ts is the last conditional-cluster Fail. Its diff is down to three independent feature areas (baseline-relative lines):

1. Mapped-type relation rules — f7/f8 (missing TS2322@106/108/115/117, extra @105/107/112/113)

FunctionProperties<T> = Pick<T, FunctionPropertyNames<T>> and the { [K in keyof T]: T[K] extends Function ? K : never }[keyof T] key-filter idiom. tsc relates these through:

• source T → homomorphic mapped target Pick<T, K> when K ⊆ keyof T (so y = x / z = x are OK),
• structural comparison of two deferred mapped/indexed key-filter types with DIFFERENT conditional templates (FunctionPropertyNames<T> vs NonFunctionPropertyNames<T> must be incompatible both ways),
• FunctionPropertyNames<T> → keyof T via the [keyof T] index upper bound (so x = y / x = z are OK).

We currently get the polarity roughly inverted (accept what tsc rejects in f7's cross-assignments, reject the keyof-upper-bound directions in f8).

2. DeepReadonly / readonly-mapped enforcement — f10 (missing TS2540@134, TS2542@135, TS2540@136, TS2339@137; extra TS2312@125, TS7053@131/133/136, TS2349@137)

Needs, in order:

• interface DeepReadonlyArray<T> extends ReadonlyArray<DeepReadonly<T>> {} accepted (we emit TS2312 — ReadonlyArray isn't modeled as an extendable interface),
• DeepReadonly<Part> evaluating through T extends any[] / T extends object to DeepReadonlyObject<Part> — a mapped type whose keys filter through NonFunctionPropertyNames<Part> (drops updatePart → TS2339@137) ,
• readonly enforcement: assignment to a readonly mapped property = TS2540, write through a readonly index signature = TS2542.

3. Assignment narrowing for generic vars with union constraints (extra TS2322@18)

function f2<T extends string | undefined>(x: T, y: NonNullable<T>) {
    x = y;
    let s1: string = x;  // tsc: NO error — x narrowed to `string` by the assignment
}

tsc narrows a reference whose declared type is a type parameter with a union constraint by assignment (the constraint is the narrowing domain). We don't narrow, so s1 = x reports the constraint error.

4. TS2403@263 — filed separately as #336 (annotation-only duplicate var skips the redeclaration check; the distributivity identity half is already in place).

Items 1+2 are the bulk and overlap with the mapped-type machinery the type-AST migration keeps routing toward; recommend treating them as one mapped-types round.

[nickna]

Progress: item 3 (assignment narrowing) done; items 1 & 2 root-caused

Working branch worktree-issue-337.

✅ Item 3 — assignment narrowing for generic vars with union constraints (extra TS2322@18)

Implemented. TypeChecker.CheckAssign now narrows a reference whose declared type is a bare type parameter after an assignment, using the assigned value's concrete base type (TypeChecker.Compatibility.Helpers.cs::AssignmentNarrowedBaseType):

• x: T (T extends string | undefined), x = y with y: NonNullable<T> → x reads as string, so let s1: string = x no longer errors.
• An unconstrained T yields no base type → left at T → f1's analogous read still errors (correct).
• A bare-type-parameter RHS (u = t with t: T) is deliberately not reduced to its constraint — reducing it regressed typeParameterAssignability2/3 (v = u in a T extends U extends V extends Date chain spuriously failed because u collapsed to Date). The helper only reduces a deferred distributive conditional (NonNullable<T>, Extract<T,…>) whose check parameter is constrained.

Confirmed against conditionalTypes1.types: tsc shows x : T at y = x but x : string at let s1 = x; narrowing to the base type reproduces both the surviving error and the dropped one. New regression test: GenericAssignmentNarrowingTests. Full unit suite (11095) + TS-conformance suite green; no baseline drift.

🔍 Items 1 & 2 — root cause (deferred, the "mapped-types round")

These remain and are genuinely one interdependent round overlapping the string→node type migration:

• Item 1 (f7/f8 polarity): FunctionPropertyNames<T> / NonFunctionPropertyNames<T> for an open T are resolved through ResolveGenericType's string-expansion path (typeArgs.Any(ContainsOpenTypeVariable) → deferred RecursiveTypeAlias, which on re-expansion with an open arg collapses the generic to any). So both key-filter aliases compare vacuously — the polarity isn't inverted by a relation rule, the types never reach the relation rules as comparable structures. The fix is to resolve { [K in keyof T]: F(K) }[keyof T] (open T) structurally to the deferred F(keyof T) = T[keyof T] extends Function ? keyof T : never (substitute the mapped parameter with the index domain), then let the existing deferred-conditional relation rules compare them. That needs the node path, not the string-expansion path — a targeted ResolveIndexedAccess/ResolveGenericType change in MappedTypes.cs had zero effect precisely because the value is a RecursiveTypeAlias, never an IndexedAccess, at relation time.
• Item 1 f7 (Pick) additionally needs the homomorphic-mapped relation T ⟶ Pick<T, K> when K ⊆ keyof T, and Pick<T, K1> ≁ Pick<T, K2> when the key filters differ.
• Item 2 (DeepReadonly) depends on item 1 (DeepReadonlyObject<T> filters through NonFunctionPropertyNames<T>) and additionally needs: modeling ReadonlyArray<X> as an extendable interface (the interface DeepReadonlyArray<T> extends ReadonlyArray<…> → TS2312 extra comes from ReadonlyArray<X> resolving to a bare TypeInfo.Array, which the interface-extends check rejects), a readonly numeric index signature on that base (TS2542), and readonly mapped-property enforcement (TS2540) + the updatePart drop (TS2339). Even the "small" TS2312 piece pulls in the readonly index-signature modeling, so it isn't cleanly separable.

Recommend keeping items 1 + 2 as a single mapped-types round taken on with / after the type-AST migration. Item 4 is tracked in #336.

[nickna]

Update: items 1 & 2 implemented (branch worktree-issue-337)

Following up — items 1 and 2 are now largely done. Full unit suite (11099) + TS-conformance suite green throughout; no baseline drift.

✅ Item 1 — f7/f8 mapped-type relations (COMPLETE)

The polarity wasn't a relation-rule bug — the key-filter aliases were being destroyed before reaching the relation:

• ResolveIndexedAccess was expanding { [K in keyof T]: F(K) }[keyof T] to an empty object (the open-T guard relied on _openTypeVariablesInScope, empty during relations). Now indexing a homomorphic mapped type by a generic key domain resolves structurally to the deferred T[keyof T] extends Function ? keyof T : never.
• Such indexed accesses are surfaced to the deferred-conditional rules before the keyof/type-parameter rules (which used to reject the raw IndexedAccess).
• Pick<T, deferredKeyFilter> stays a MappedType (no eager expansion to {}) and relates structurally via a new TryRelateDeferredMappedType: two key-filter Picks compare by keys(target) ⊆ keys(source) + value covariance; a homomorphic Pick<T, K> ← T is accepted when K ⊆ keyof T.

All of f7 and f8 now match the baseline.

✅ Item 2 — DeepReadonly (mostly done)

• NonFunctionPropertyNames<Part> now actually drops function-typed keys: ExpandMappedType substitutes the value conditional without eager eval, resolves the T[K] check to the concrete member, then evaluates — and X extends Function (infer-free) now uses assignability rather than strict signature unification (a (s: string) => void IS a Function). → part.updatePart(...) = TS2339.
• readonly [P in K] mapped types propagate the read-only modifier into Interface.ReadonlyMembers; interface property writes check it. → part.id = … = TS2540.
• interface … extends ReadonlyArray<E> / Array<E> is accepted (no more TS2312) and modeled with a numeric index signature (read-only for ReadonlyArray, new Interface.ReadonlyNumberIndex); writes through it = TS2542. Works end-to-end for non-recursive cases (incl. RA<T> via flatten).

⏳ Remaining (filed #365)

Only the recursive array case in f10 is left: part.subparts (DeepReadonly<Part[]>) must resolve to DeepReadonlyArray<Part> to index — forcing that re-enters the self-referential chain and trips the TS2589 depth guard, so recursive aliases are left deferred for now (residual TS7053 on part.subparts[0], blocking TS2542@135 / TS2540@136). Needs the lazy/identity-cached recursive resolution from the #185 family — tracked in #365.

So conditionalTypes1.ts will flip to Pass once #365 + #336 (TS2403, shipped in PR #364) land. New tests: GenericMappedTypeRelationTests, GenericAssignmentNarrowingTests.

[nickna]

Closing — all four work items landed and conditionalTypes1.ts is Pass in the committed conformance baseline.

• Item 1 (mapped-type relations f7/f8) & Item 3 (generic assignment narrowing) — e47e48d6
• Item 2 (DeepReadonly / readonly-mapped f10) — e47e48d6; recursive array-element residual spun to DeepReadonly over self-referential interface: recursive array-element index access trips depth guard #365, fixed in 1c4ce803 (PR fix(types): resolve recursive DeepReadonly array-element indexing (#365) #412)
• Item 4 (TS2403 annotation-only duplicate var) — spun to TS2403 not reported for annotation-only duplicate var declarations #336 → PR fix(check): report TS2403 for annotation-only duplicate var declarations (#336) #364 (merged)

All spun-off blockers (#336, #364, #365) are closed/merged. No remaining work under this issue.

The last open Fail in the configured conformance subset is assignmentCompatWithStringIndexer3.ts (load-bearing any-fallback for unknown annotation names); it's tracked under #226, not here.