Class CloseableNotInGenericParameterOrError

java.lang.Object
org.ek9lang.compiler.common.RuleSupport
org.ek9lang.compiler.support.CloseableNotInGenericParameterOrError
All Implemented Interfaces:
Predicate<ParameterisedTypeData>
final class CloseableNotInGenericParameterOrError extends RuleSupport implements Predicate<ParameterisedTypeData>
THE rule that a closeable type is never a type argument (E81061, Steve 2026-10-06, option A - strict).

A closeable value has exactly one owner, and the compiler must be able to see that owner close it: a try resource, a property closed in its type's operator close, or the caller of a callable that returns a new one. A generic type or function has no such owner - List of TCP, Optional of TCP, Dict of (String, HTTP), a user Box of Res or Acceptor of TCP hold or pass the value where no operator close and no try reach it. So the parameterisation is refused whether it is written (List of TCP) or inferred ([TCP(...)], Optional(res), {k: res}, a generic function called with a closeable) - both reach here through ResolverOrDefiner. A closeable may still be a PARAMETER type: that is a loan, and the lender keeps ownership.

What is closeable is CloseableResourceToBeChecked.isManagedCloseableType(ISymbol), the one predicate the ownership rules share (the standard streams and a bare conceptual T are not). The other half of the rule - a generic's T constrain by Res with Res closeable - is in phase 2's SetupGenericTOrError, which asks the same predicate.

There is NO exemption for the compiler's own parameterisations: SynthesizeSuperFunction, which gives a function its implicit Acceptor of T / Consumer of T / Supplier of T ... super, declines to synthesise one over a closeable type (its super is then Any), so this rule holds on every path (D7, Steve 2026-10-06 - the exemption, the four synthesised wrappers over TCP/HTTP and their unresolved-call ratchet bump were removed together).