Answer.

In Kotlin, functions are declared very concisely, which is one of the language's strengths. Historically, in Java, functions are tightly coupled with classes (methods), do not support named parameters and default parameters, which often requires creating overloaded methods. In Kotlin, functions can be declared at the top level, and their parameters are much more flexible.

Problem in Java: for different combinations of arguments, it is often necessary to create separate overloads. This leads to excessive code and complicates maintenance.

Solution in Kotlin:

support for default parameters,
named parameters,
function declarations outside of classes.

Code example:

fun greet(name: String = "User", greeting: String = "Hello") {
    println("$greeting, $name!")
}

greet() // Hello, User!
greet("Alex") // Hello, Alex!
greet(greeting = "Hi", name = "Olga") // Hi, Olga!

Key features:

Default parameters reduce the number of overloads and improve readability.
Named parameters increase code expressiveness and prevent mistakes with long argument lists.
Free function declaration (top-level) simplifies code organization.

Trick questions.

Are default arguments part of the function signature in bytecode?

No, Kotlin compiles separate synthetic overload methods to ensure compatibility with Java, but the function signature does not change at the JVM level.

What happens if the order of named and positional arguments is mixed up?

Positional arguments must come before named arguments; otherwise, a compilation error will occur.

Example of incorrect usage:

greet(greeting = "Hey", "Ivan") // Compilation error

Can functions be declared outside of classes in Java as in Kotlin?

No, in Java, every function must necessarily be a method of some class. In Kotlin, top-level functions are allowed — this makes the code cleaner and more testable.

Common mistakes and anti-patterns

Attempting to mix named and positional parameters in the wrong order.
Expecting Java code to support Kotlin's default arguments — overloads must be created manually in Java, or use @JvmOverloads.
Unjustified use of a large number of parameters which reduces readability.

Real-life example

Negative case

In a large Android project, a developer implemented API client methods with 5-6 positional arguments and overloads, leading to frequent errors in calls and large duplicated code blocks.

Pros:

Compatibility with Java code

Cons:

Complexity of support
A lot of code
High probability of errors

Positive case

Using functions with default parameters and named parameters resulted in a compact signature, eliminated the need for overloads, reduced the risk of errors, and improved the maintainability of the API.