In cases when

this

is not meaningful enough you can use e.g.

let()

or even assign this to variable

val self = this

the point of extention function is to kill boilerplate of util-classes in java, that's all. Argument naming does not contradict to it!

val meaningfulName = this

is too verbose for such reasons

Right, in those cases

this

is perfectly clear. Can you give an example where it's not and you couldn't just replace it with a normal function?

I always can replace extension. But I loose the implicit argument passing then. The question is why I can not have a name/alias in extension? It is not always clear and expressive. I would say

this

is enough only in short 1-2-3 liners, with almost no logic inside.

Because any alias you could give it would be less clear than

this

. It has a very specific meaning in OOP. If your methods are so long you forget what

this

refers to halfway through you're doing something wrong.

I have to use extra

val

for naming an argument with extensions, thought there is no any limitation just for having an alias

You still haven't given an example of where you'd want to do this...

Is there a reason why named arguments / default arguments do not get inlined by the compiler? Why does the compiler generate a bit field which is used to set arguments at runtime instead of just inlining the arguments at run time? Example:

fun x(a: Int = 1)

used as

x()

would be compiled as

x(1)

.

@pim Because the method might be in a library and the default value might change. You'd then have to recompile with the new version of the library to get the updated defaults.

@diesieben07 I'd prefer that behaviour over runtime setting the values. Maybe it should be a compiler option?

Why do you prefer it?

@diesieben07 I don't like unnecessary performance hits, it can be inlined which would result in 0 performance difference over regular Java.

Waiving around the "performance problem" flag is not very helpful. The JVM is great at optimizing this. Measure if you have a performance problem first.

@diesieben07 I'm not sure about this, but I think the compiler adds this logic any time you use named arguments, even when you specify all arguments. I like to use named arguments for clarity, but I don't want the compiler to add unnecessary extra logic because of this.

It has to. The library might reorganize the parameter order and you don't want your user code to suddenly fail with cryptic error messages because the parameter order no longer lines up.

That is also the reason why you can only use named parameters when the target method is written in Kotlin

Hey I am writing article about function arity and have interesting question. What is the arity of this function that uses unpack operator.

sum(*list)

Should we say arity is 1 or should new say that arity equals to number of elements in the list?

I would just say arity of 1.

vararg

is really just syntactic sugar for an

Array

argument

When creating a data class with a private constructor, a warning is shown that the constructor is exposed via the copy method. Is it possible to not generate that copy method? Currently I have to not mark it as a data class and implement(/generate) the

toString()

,

equals()

and

hashCode()

methods myself 😕

I think there is an issue to set the `copy`‘s visibility to be the same as the constructor’s

I have only found issue KT-15709 that introduces the warning (https://youtrack.jetbrains.com/issue/KT-15709), do you have the issue for that?

https://youtrack.jetbrains.com/issue/KT-11914 probably

Thanks!

why kotlin designers decided to use

fun

keyword instead of none like in java?

in java you explicitly say what type the function returns, here you don't have to. instead you mark it with

fun

so is it only readability concern? because for me

foo()

is readable enough

how do I call optional closure?

how would you distinguish between function declaration and invocation ?

@User uploaded a file: Untitled