What causes "wrongTypeArgumentCount (expected, actual)" in apple/pkl?

Match the argument count to the alias's declared type parameters (read the alias definition)

wrongTypeArgumentCount

wrongTypeArgumentCount

Error message

wrongTypeArgumentCount (expected, actual)

What it means

When constructing a TypeAliasTypeNode for a parameterized type alias, the number of supplied type-argument nodes must equal the alias's type parameter count. If at least one argument is given but the counts differ, Pkl throws an evalError `wrongTypeArgumentCount(expected, actual)` with the expected and actual counts.

Source

Thrown at pkl-core/src/main/java/org/pkl/core/ast/type/TypeNode.java:2752

  public static final class TypeAliasTypeNode extends TypeNode {
    private final VmTypeAlias typeAlias;
    private final TypeNode[] typeArgumentNodes;
    @Child private TypeNode aliasedTypeNode;

    public TypeAliasTypeNode(
        SourceSection sourceSection, VmTypeAlias typeAlias, TypeNode[] typeArgumentNodes) {
      super(sourceSection);

      if (!typeAlias.isInitialized()) {
        CompilerDirectives.transferToInterpreter();
        throw exceptionBuilder().evalError("cyclicTypeAlias").build();
      }

      if (typeArgumentNodes.length > 0
          && typeArgumentNodes.length != typeAlias.getTypeParameterCount()) {
        CompilerDirectives.transferToInterpreter();
        throw exceptionBuilder()
            .evalError(
                "wrongTypeArgumentCount",
                typeAlias.getTypeParameterCount(),
                typeArgumentNodes.length)
            .build();
      }

      this.typeAlias = typeAlias;
      this.typeArgumentNodes = typeArgumentNodes;
      aliasedTypeNode = typeAlias.instantiate(typeArgumentNodes);
      aliasedTypeNode.accept(
          node -> {
            if (node instanceof ValidatingObjectSlotTypeNode typeNode) {
              typeNode.validate(this);
            }
            return true;
          });
    }

View on GitHub (pinned to f3efcbfc9b)

Solutions

Match the argument count to the alias's declared type parameters (read the alias definition)
Remove extra type arguments or add missing ones
Replace a one-parameter alias with a class if you need multiple parameters
Search usages of the alias after changing its parameter count

Example fix

// before
typealias Box<T> = ...
val b: Box<Int, String> = ...
// after
val b: Box<Int> = ...

Defensive patterns

Strategy: type-guard

Validate before calling

// pkl: typealias Box<T> — count <T> params and apply exactly that many arguments

Prevention

Check the alias declaration's <T,...> parameter list before applying type arguments
Update all application sites when changing a generic alias's parameter count
Avoid guessing stdlib generic arity — consult the API docs

When it happens

Trigger: Writing `Foo<Int, String>` where `typealias Foo<T>` takes one parameter, or `Pair<Int>` where Pair expects two; programmatically building typecheck nodes with a mismatched typeArgumentNodes array.

Common situations: Copy-pasted generic applications missing or extra type arguments; misremembering a stdlib alias's arity (e.g. `List<Int, String>`); refactor changing a parameter count without updating all usages.

Related errors

AI-assisted analysis of apple/pkl@f3efcbfc9b (2026-09-08). Data as JSON: /api/errors/cf73d38822a5e098. Report an issue: GitHub.