To address the error "Kotlin: Wrapped into a reference object to be modified when captured in a closure," you can follow the solution below. This error commonly occurs when you try to modify a variable captured in a closure that is declared outside the closure's scope. Kotlin handles capturing variables differently from some other languages, which can lead to unexpected behavior if not understood correctly.

Here's a detailed explanation along with an example:

// Define a function that takes a lambda as an argument
fun modifyVariableInClosure() {
    var counter = 0 // Variable declared outside the lambda's scope

    val incrementCounter: () -> Unit = {
        counter++ // Trying to modify the counter variable
        println("Counter inside closure: $counter")

    // Call the lambda

    println("Counter outside closure: $counter")

// Call the function


In this example, we have a function modifyVariableInClosure that contains a local variable counter. Inside the function, we define a lambda incrementCounter that captures the counter variable.
The lambda tries to modify the counter variable by incrementing it.When we call the lambda incrementCounter(), it modifies the counter variable as expected within its scope.
However, if we try to access counter outside the lambda's scope, Kotlin gives an error because the counter variable is effectively "captured" by the lambda and treated as a reference, causing unexpected behavior.

To prevent this error and ensure the expected behavior, you can use Kotlin's immutable references (val) or make a defensive copy of the variable if mutation is required outside the closure.

Example with immutable reference (val):

fun modifyVariableInClosureFixed() {
    var counter = 0

    val incrementCounter: () -> Unit = {
        val currentCounter = counter // Immutable reference
        counter = currentCounter + 1 // Modify the copy
        println("Counter inside closure: $counter")


    println("Counter outside closure: $counter")

We create an immutable reference currentCounter inside the lambda, and then modify the original counter variable based on this reference.

In Kotlin, we create function references using the :: operator, not the dot operator.

Our intended use case can be easily achieved using this approach:

val eventHandlers: HashMap<RemoteEvent, (bytes: ByteArray) -> Unit> = hashMapOf(
    0x01 to Product::handleEvent,
    0x02 to Customer::handleEvent)

When we use Product.handleEvent, it's interpreted as accessing a property called handleEvent, which may not exist.

However, Product::handleEvent represents a KFunction instance, which matches the lambda signature (ByteArray) -> Unit, and thus works as expected.

This differs from languages like C# or C++, where methods and properties/fields cannot share the same name due to language restrictions. In such languages, using the dot operator for method groups or function pointers is fine because ambiguity between methods and properties/fields is impossible.