I’m not sure that there’s a conflict between OOP a...

# language-proposals

[dalexander]

I’m not sure that there’s a conflict between OOP and PA. As Ilya pointed out earlier, PA can be looked at the general case of bound method references, except parameters as well as the receiver can be bound.
Using the imaginary _ syntax to indicate parameters which are left open:
fooObject::fooFunction is the same as { p1, p2, p3 -> fooObject.fooFunction(p1, p2, p3) }
so
fooObject::fooFunction("value1", "value2", _) is the same as { p3 -> fooObject.fooFunction("value1", "value2", p3) }
If we want a general FooObject::fooFunction with the first two parameters applied but not bound to an object then
FooClass::fooFunction("Hello", "Functional", _) would be the same as FooClass.(String) -> Unit = { p3 -> this.fooFunction("Hello", "Functional", p3) }
I haven’t seen this mentioned, but one of the major advantages for having language support for PA would be the preservation of parameter names (and parameters with default values?), which tend to be lost with library-provided PA as far as I’ve seen.
I don’t know how frequently I would use this feature in Kotlin, but it seems like it would fit reasonably well with the rest of the language, so I’d like to see examples or edge cases where there would be issues.

[dmitry.petrov]

That's just a syntax sugar, and it's advantages are not quite clear. You can just replace it with a lambda such as { foo.bar(x1, it, x2) }.
The question is why is that syntax sugar really needed.

[dalexander]

I would argue that fooObject::fooFunction serves as a precedent, and this would just be an expansion of that functionality. My primary argument in that post is not if it should be added or not, just that 1) doesn’t interfere with existing functionality and 2) Some functionality that would make PA/currying better integrate with other Kotlin code can’t be supported with just libraries.
I think that there’s probably some good use cases for it, but I don’t have any compelling examples to provide so I’m not supporting it on that axis 🙂

[dmitry.petrov]

Callable references as foo::bar above has some extra semantics (reflection stuff). That's somewhat unfortunate from the low-level metrics point of view, because it's a simple way to introduce extra methods that would never be invoked, but are quite hard to get rid of.

Other than that, my point was not about some "formal" conflict between PA and OOP, but rather about practical impact on API design. In ML family, PA is used mostly often to build function pipelines, as in xs |> List.filter ... |> List.map .... In the world of functions with receivers,... (see above)