Extension Functions & Properties

An extension function lets you add a new function to an existing type without changing its source. You write the type name before the function name, like fun String.shout(), and call it as if it were a normal method.

An extension property lets you add a property to an existing type without changing its code. You write it like val String.lastIndex with a custom getter that computes the value.

An extension defined elsewhere is only visible if you import it by name. Add an import line for that function, then call it like normal. Member functions come for free with the object's type, so they need no import.

The member function always wins. When the name and parameters match, Kotlin calls the function defined inside the class and ignores your extension. The extension is effectively shadowed.

The function is declared on a type that allows null, so you can call it even when the value is null. Inside, you check for null yourself. No crash, because no method is dispatched on the object.

Overridden members run based on the real object (virtual dispatch). Extensions run based on the variable's declared type (static). So members can be polymorphic; extensions cannot.

Kotlin compiles an extension into a plain static method. The object you call it on is just passed as the first hidden argument. So a.foo() really becomes Foo.foo(a) at the bytecode level.

A backing field is hidden storage attached to an instance. Extensions don't own the class, so they can't add storage. The value must be calculated each time in the getter; you can't use field.

From Java, the extension is a static method on the file's facade class. You pass the receiver as the first argument: instead of 'hi'.shout() you write StringUtilsKt.shout("hi"). Extra parameters follow the receiver.

Both work on any type because they take a generic receiver T. also passes the object as it and returns it; apply makes the object the lambda's this and also returns it. Both return the original object.

Inside the body, this is the object the function was called on (the receiver). You can write this to refer to it, or just call its members directly without this, like in a normal method.

Extensions are picked by the declared type. A List extension isn't visible on a Collection-typed variable, because the compiler only sees Collection. Members would be inherited and resolved on the object instead.

Use an extension when you want a method-like helper on a type you don't own or want to keep the class small, and the helper only needs the type's public API. Use a member when it needs private state or should be overridable.

A mutable extension property's setter must change something that already exists on the receiver — like calling a method that mutates it. It can't store the value itself because there's no field.

Top-level Kotlin functions and extensions compile into a hidden class named after the file (e.g. Utils.kt becomes UtilsKt). @file:JvmName lets you rename that class so Java code calling it sees a nicer name.

If the parameters differ, the member and the extension are just two overloads. Kotlin picks by matching your arguments to the parameter lists, so both can be reachable depending on what you pass.

Extensions are resolved by the compiler from the static type, not by the object at runtime. Letting them beat members would let any import silently change a class's behavior, so the member is kept authoritative.

Inside, this may be null, so test it. After if (this != null) the compiler narrows the type to non-null, letting you use it safely. Or just use Elvis: return this ?: default.

The class instance (dispatch receiver) is polymorphic and chosen at runtime. The extension receiver (the type after the dot) is fixed at compile time. So overriding can change the object's behavior but not which extension target is picked.

An extension follows normal visibility rules for where it is declared, not the type it extends. A top-level public extension is usable anywhere; a private one only in its file. Because it sits outside the class, it can only see that type's public members.

On the JVM it becomes a plain static method (a getter, and a setter for var) that takes the receiver as its first argument. There is no field; calling the property just calls that static method.

Generic types erase at runtime, so two Kotlin extensions that look distinct can compile to the same JVM signature and clash. Putting @JvmName on one of them gives it a different method name so both can coexist.

Yes — the same rule holds. A member property always wins over a same-named extension property. The extension property is shadowed and never read or written through the instance.

A nullable-receiver extension runs even when the value is null and decides what null means. With a non-null receiver and ?., the whole call is skipped when null and the result is null. They behave differently for null inputs.

You need reified only when the function must know the real type at runtime — to do is T, as? T, or T::class. The function must be inline. Then you can write helpers that safely cast or filter by type.

Use an extension property for a cheap, no-argument, value-like accessor that reads naturally as a noun. Use an extension function when it takes arguments or does real work. Use a real member when you own the class and need stored state.

Internal extensions get a mangled, hard-to-call name from Java, so don't expect clean access. To group several files' top-level functions under one Java class, give each file the same @file:JvmName plus @file:JvmMultifileClass.

Use extensions for convenience helpers that shouldn't be overridden or pollute the type, and where uniform per-declared-type behavior is fine. Use open members when subtypes must customize behavior polymorphically.

Once your member exists, calls of the same signature start hitting the member instead of the consumer's extension. The code still compiles, but its behavior may change because the member now wins.