Why can't I use an abstract function as a return type directly in EK9?

← Code Quality · Ref: Q831

EK9 prevents using abstract function types directly as return types via built-in constructors like Function(). Abstract functions define contracts — they must be implemented concretely.

THE RULE

You cannot return an abstract function type via its constructor:

  getHandler()
    <- rtn as Function of (Integer, String): Function  // ERROR

HOW TO FIX

- Return a concrete implementation of the abstract function
- Use a dynamic function to create an inline implementation
- Declare the return type as the abstract function but assign a concrete one

WHY THIS MATTERS

Abstract functions have no implementation. Constructing one would create a callable with no body — which would fail at runtime. EK9 catches this at compile time.

See Q821 for abstract type construction. See Q126 for function patterns.

Example

defines module qa.quality.abstract.function

  defines function

    abstractGreet() as abstract
      <- rtn as String?

    concreteGreet() is abstractGreet
      <- rtn <- "Hello from concrete"

    getGreeting()
      <- rtn as String: concreteGreet()

  defines program

    AbstractFunctionDemo()
      stdout <- Stdout()

      // === CORRECT: use concrete function ===
      greeting <- getGreeting()
      stdout.println(greeting)

Common mistakes

E50080 — Abstract functions cannot be called directly — they have no implementation. Use a concrete function that extends the abstract one. See ek9 -h E50080 for details.

Incorrect:

      <- rtn as String: abstractGreet()

Correct:

      <- rtn as String: concreteGreet()

Coming from another language?

Java: cannot instantiate abstract classes or interfaces directly. Python: ABCMeta raises TypeError. Rust: traits cannot be constructed. Go: interfaces have no constructors. EK9: compile-time error for abstract function construction.

Keywords: function, abstract, concrete, return, E50070, implementation, type