Intersection spellings of callable shapes are half accepted and half rejected

[samchon]

Problem

A member-carrying callable type has two equivalent spellings: a declaration body, and an intersection of a call signature with the rest. typia treats the intersection spelling inconsistently — it accepts six of these shapes and rejects six structurally analogous ones as a nonsensible intersection.

Where it rejects, the intersection also disagrees with the declaration spelling of the same type, which is accepted. So the same type is supported or refused depending on how it was written, and which way it goes is not predictable from any stated rule.

Evidence

Measured on master at ab978b0a27, transforming one single-shape project per spelling and recording the exit code and diagnostic counts. Each row is the same type written two ways.

Shape	Interface spelling	Intersection spelling
Method	code=0	code=0
OptionalMethod	code=0	code=0
OptionalMethodProperty	code=0	code=0
OptionalMember	code=0	code=0
SymbolMember	code=0	code=0
OptionalSymbolMember	code=0	code=0
Overload	code=0	code=3, 2 nonsensible
ConstructOverload	code=0	code=3, 2 nonsensible
CallAndConstruct	code=0	code=3, 2 nonsensible
MethodProperty	code=0	code=3, 2 nonsensible
RequiredMember	code=0	code=3, 2 nonsensible
IndexSignature	code=0	code=3, 2 nonsensible

Two diagnostics per rejected row because the fixture exercises both the direct and the factory form.

The split is not random, which is what makes it worth stating precisely rather than as "sometimes":

• Method is accepted while MethodProperty is rejected — cancel(): void and cancel: () => void are the same type.
• OptionalMember is accepted while RequiredMember is rejected — the only difference is ?.
• Every shape whose intersection combines two call signatures (Overload, ConstructOverload, CallAndConstruct) is rejected.

Owner: packages/typia/native/core/factories/internal/metadata/iterate_metadata_intersection.go. The accept path is if onlyObjects && len(tagObjects) == 0 { return escape(false) }; the reject path is reached when a surviving member is not a single-bucket object after phantom brands are dropped.

Consequence surface

• Any typia.* operation on a type spelled as an intersection of a call signature with further members, in direct and factory forms.
• A refactor that TypeScript considers a no-op — cancel(): void to cancel: () => void, or adding ? to a member — flips a project between compiling and failing.
• Downstream generators that emit intersection spellings cannot predict which of their outputs typia will accept.

Invariant

Equivalent spellings of one type receive one answer. Whether that answer is "supported, treated structurally" or "rejected with a diagnostic" is a product decision, but it must not depend on the spelling, and it must not differ between two shapes that TypeScript considers the same type.

Note the interface spelling is already settled: #2250 established that a member-carrying callable stays structural, and all twelve shapes above are accepted that way. Aligning the intersection spelling with it would make the contract uniform without changing any currently accepted behaviour.

Acceptance and verification

• For each of the twelve shapes, the interface, named-type-literal, inline-literal, and intersection spellings report the same exit code and the same diagnostics.
• cancel(): void and cancel: () => void agree; the optional and required forms of one member agree.
• A genuinely nonsensible intersection — two unrelated atomics, say — is still rejected, so the alignment does not blanket-accept.
• The regression fails when only the alignment is reverted.

Coordination

Found while verifying #2238, which owns the declaration spellings and is not the cause: its own regression measured this while establishing that interface, named type literal, and inline literal agree. Its author had assumed from source reading that typia rejects every such intersection and pinned that as a hand-over point; execution shows it rejects only half of them, so the assumption was wrong in both directions and that expectation is being removed there rather than restated.

[samchon]

Investigation state, so the next attempt starts from where this one stopped rather than from the symptom.

Narrowed to the arm-classification stage in iterate_metadata_intersection.go. The accept path is if onlyObjects && len(tagObjects) == 0, and onlyObjects requires every surviving arm to have exactly one Objects entry. A bare function type contributes Functions, not Objects, so on that rule alone every one of the twelve intersections should fall through to the len(metadatas) != 1 rejection — yet six are accepted. Something removes an arm before that check.

The candidate is the phantom-brand pass immediately above it:

removable := []int{}
for i, m := range metadatas {
  if iterate_metadata_intersection_is_removable_brand(m) { removable = append(removable, i) }
}

with

func iterate_metadata_intersection_is_phantom_property(p *MetadataProperty) bool {
  if p.Value.Optional { return true }
  return iterate_metadata_intersection_is_symbol_key(p.Key)
}

That rule — every property optional or symbol-keyed — explains five of the six accepted shapes exactly: { method?(): void }, { method?: () => void }, { label?: string }, { [callableBrand]: string }, { readonly [callableBrand]?: never }. It does not explain Method ({ method(): void }), which is required and string-keyed and is nevertheless accepted, so either a method property is not reaching object.Properties the way a data property does, or that arm's metadata is not an object at all.

Resolving that one discrepancy is the next step, and it decides the shape of the fix: if the accepted set really is "the extra arm is a phantom brand", then the fix is to stop treating a callable arm as disqualifying rather than to widen the brand rule.

Not attempted here: the fix itself. Two instrumentation attempts were made and both were abandoned — the ttsx debug runner is blocked by unrelated TS6196 diagnostics from typia's own source under that workspace's compiler options, and the in-process Go harness rebuild exceeded the time available. The instrumentation was reverted and the working tree is clean at 8f4f951cc0; nothing from this attempt is left behind.

The twelve-shape table in the issue body is unchanged and was measured, not inferred.

[samchon]

Second investigation round. Re-measured on current master and recorded three dead ends so the next attempt does not repeat them.

The split is unchanged on 8f4f951cc0. Re-running the twelve-shape matrix with an agreement assertion reports exactly six disagreements, and the other six now agree:

MEASURE Overload:          alias=code=3 nonsensible=2  interface=code=0 nonsensible=0
MEASURE ConstructOverload: alias=code=3 nonsensible=2  interface=code=0 nonsensible=0
MEASURE CallAndConstruct:  alias=code=3 nonsensible=2  interface=code=0 nonsensible=0
MEASURE MethodProperty:    alias=code=3 nonsensible=2  interface=code=0 nonsensible=0
MEASURE RequiredMember:    alias=code=3 nonsensible=2  interface=code=0 nonsensible=0
MEASURE IndexSignature:    alias=code=3 nonsensible=2  interface=code=0 nonsensible=0

So neither #2270 nor #2277 changed it, and the accepted six are accepted rather than merely untested.

An unresolved contradiction, which is the useful part. nonsensible intersection has exactly one producer in the tree — the nonsensible() closure in iterate_metadata_intersection.go. Yet tracing the entry of Iterate_metadata_intersection, immediately after its Intersected and IsIntersection() guards, printed nothing across the whole matrix while the same run still produced those six diagnostics. Both observations cannot be right. Either the trace never executed for a reason I did not establish, or the message reaches these fixtures through a path that does not enter that function.

Resolving that is the next step and it should come before any fix. Instrumenting the producer — printing at nonsensible() itself with the type name and a stack marker — answers it in one run and is what I would do first.

Three dead ends, recorded so they are not repeated:

1. The ttsx debug runner (tests/debug) cannot be used for this: that workspace's compiler options make typia's own src/json.ts and src/llm.ts report TS6196/TS6205, which stops the run before any transform.
2. Two instrumentation attempts failed to compile — a duplicated fmt import and a literal newline inside a format string — and I did not notice for two long build cycles because I piped the run through grep and read "no output" as "still building" instead of checking the exit status. That is the same false-green pattern this campaign has been fixing; checking EXIT= on every probe is the cheap fix.
3. GOMAXPROCS=1 with a source edit in core/factories/internal/metadata invalidates a large part of the build graph; each probe cost roughly ten minutes. GOMAXPROCS=2 and -p 2 brought the same cycle under one minute once the cache was warm.

All instrumentation has been reverted and the working tree is clean at 8f4f951cc0. The twelve-shape table in the issue body remains the measured ground truth.

[samchon]

Third round. One fact established, and it eliminates the hypothesis both earlier rounds were built on.

The nonsensible() producer is never invoked for these fixtures. Instrumenting the closure itself in iterate_metadata_intersection.go — the only place in the tree that emits the string nonsensible intersection — and running the twelve-shape matrix printed zero hits, on a run that compiled and passed (EXIT=0, ok … 16.6s) while the same matrix still reports nonsensible=2 for the six disagreeing shapes.

Combined with the previous round, where tracing the entry of Iterate_metadata_intersection after its Intersected and IsIntersection() guards also printed nothing, the conclusion is that the diagnostic these six shapes receive does not originate in the intersection iterator at all. Every hypothesis about onlyObjects, the phantom-brand pass, and is_removable_brand — mine included, in the comment above — is therefore aimed at the wrong function.

Where to look next, in order:

1. Print the raw errText for one rejected shape, e.g. RequiredMember/Alias, from the twin loop in callable_type_literal_boundaries_transform_test.go. The diagnostic's own position and wording will name its source directly, and the count-based strings.Count(errText, "nonsensible intersection") the matrix uses hides exactly that.
2. If the text does come from typia, find the second producer — the string may be assembled rather than written literally, which is why a grep for it finds only one site.
3. Only then decide the fix.

Tooling notes, because four instrumentation attempts were lost to them and not to the problem:

• A bash heredoc consumes \n before Python sees it, so a format string written that way lands in Go as a literal newline and fails to compile. Edit the file directly instead.
• iterate_metadata_intersection.go already imports fmt; blindly prepending it duplicates the import.
• python3 is not on PATH in this shell; python is.
• GOMAXPROCS=2 with -p 2 keeps the edit-build-run cycle near a minute once the cache is warm, against roughly ten minutes at GOMAXPROCS=1.
• Check EXIT= on every probe. Two of the four attempts were build failures that looked like slow builds because the output was piped through grep.

The working tree is clean at 8f4f951cc0 and no instrumentation remains.

[samchon]

Root cause located. The two earlier rounds' hypotheses are all wrong, and so is the framing in the issue body — this is not a phantom-brand or arm-classification question.

The diagnostic, captured raw, for the RequiredMember twin whose fixture is valid TypeScript:

type Target = ((value: number) => string) & { label: string };

- unknown & __type
  - nonsensible intersection

The function arm is unknown. Under default options typia does not model a function type — that is the documented lenient behaviour, and it is why typia.is accepts any value in a function slot. Inside an intersection that leniency stops being lenient: the arm carries no metadata, the intersection becomes unknown & __type, and it is refused as unrepresentable.

The interface spelling of the same type never reaches this code at all. interface Target { (value: number): string; label: string } is one object with a call signature, so the signature is ignored and label is validated — accepted. That is the whole asymmetry: one spelling routes through intersection exploration and the other does not, and only the first has to represent a function type it has no representation for.

That also resolves the contradiction recorded above. Iterate_metadata_intersection is entered and nonsensible() is what produces the message; the earlier probes that printed nothing were measuring runs that had not rebuilt what I thought they had.

One candidate fix ruled out by execution. Child exploration forces options.Functional = false, which looked like the erasure. Preserving the caller's value changes nothing — functional is already false by default, so the arm is unknown either way. Reverted.

The shape of a real fix, for whoever takes it: an arm that is a pure function type with no representable metadata should be removable the way a phantom brand is, so unknown & __type reduces to __type and the intersection lands exactly where the interface spelling lands. That is a change to intersection semantics rather than to a predicate, so it needs its own consequence matrix — in particular a genuinely nonsensible intersection such as two unrelated atomics must still be refused, and functional: true must keep requiring a real function.

Not attempted: the fix. I stopped at the located cause rather than change intersection semantics on a speculative pass. The twelve-shape table in the body is still the measured ground truth; only its explanation changes.

Working tree clean at 5af6ddc83b, no instrumentation left behind.