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

#!ek9
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: E50070, abstract, concrete, function, implementation, return, type