hoang: sorry, I conflated "Go to Declaration" with "Go To Type Declaration". You're right then

So we have extension functions fun Iterable<T>.plus(element: T) for appending to iterables and collections. Should we not also have fun T.plus(iterable: Iterable<T>) for prepending?

I keep running into this all the time in my current project, where the order of things matter and I frequently need to prepend rather than append

Untitled.kt

that sounds like a reasonable thing to have, yes. maybe file an issue in youtrack about it?

I’m almost 100% sure JB won’t add such function

adding an extension function on

T

will pollute a global namespace

I don't like

+

for collections at all. But it seems I'm among the minority at JB simple smile

dmitry.petrov: I don't think it makes sense to have if it's not available for both sides

Feels very inconsistent, at best

you mean like

to

? simple smile

Mike, could you elaborate what you mean?

In my mind it makes more sense to model binary functions as functions that operate on two values: plus(a: T, b: T). Why are plus, minus etc. unary member functions?

sorry, i was unclear. i was responding to Vladimir

Oh, right

kotlin already adds the

to

method to every possible object/value, which is of perhaps more limited utility than what you're suggesting

Ah, I see

to

shouldn’t exist imo

+1,

to

seems like a workaround for not having map literals

OK, so I suppose I could make an issue on YouTrack for the missing + prepend operation for collections/iterable and see what people say?

How using the Scala’s cons operator

::

?

Mitchell, while I really like a large portion of Scala's design, in my opinion its extreme emphasis on custom operators detracts from readability and increases cognitive load. Working with Kotlin now, while slightly less powerful in its syntax, feels more right and results in code that I would call more readable than similar code I've written in Scala using said operators

Noted simple smile

I still don't understand why these operators are not standalone binary functions though. Is there a reason you couldn't have had something like operator fun <T> plus(a: T, b: Iterable<T>) = ... operator fun <T> plus(a: Iterable<T>, b: T) = ... I must admit I don't have the faintest idea of Kotlin's (or most of the JVM's for that matter) inner workings, so I would appreciate if someone could enlighten me on this

Yeah, create a YouTrack issue, that'll get the attention of the 'Brains

I think it was made for purity of language design. I mean there’s a mechanism how you can add a function to an existing class that is extension functions. So why adding another way of creating extension functions just for operators?

yes, indeed

the IDE already knows how to do scoped lookups with extension functions

But wouldn't it be even better not to add it to the existing class at all...?

From JVM point of view

fun <T> T.plus(iterable: Iterable<T>): List<T>

is exactly the same as

fun <T> plus(value: T, iterable: Iterable<T>): List<T>

.