Proposal: apply operator I find myself often in th...

# language-proposals

[Ruckus]

Proposal: apply operator
I find myself often in the situation where I create a new thing and have to call a single method on it as part of setting it up. The common form is to use val thing = Thing().apply { setup(...) }. While this is simple enough, I do it so often it would be nice to have an operator for it, that calls the function, but ignored the return value and returns the receiver instead, so I could do something like val thing = Thing()&.setup(...)
This may just be to my style of programming, but I figured I'd throw it out there to see if anyone else is interested.

[dalexander]

I do this pretty often myself. I'm not sure if it's quite worthy of an operator, but it does remind me of the pipeline operator some languages have (like Elixer I think?)

[kevinmost]

does this mean you'd be able to do makeThing()?&.setup()?

[Ruckus]

@kevinmost I guess so. I'm not tied to the &. syntax, but I see no reason it couldn't just apply to anyhing. Basically it would just be an operator that calls a function and returns the receiver, so it could safe accessed or chained.

[Ruckus]

Maybe use ^ or \? (`Thing()^setup()`: makeThing()?^setup(), `Thing()\setup()`: makeThing()?\setup())

[Ruckus]

Both of those look pretty ugly too 😛

[kioba]

isn’t this that you are looking for?
https://pl.kotl.in/Jlu_woa27

instead of an operator you could create an infix

[Ruckus]

No, thats the definition of apply (albeit with an infix). You can already to .apply(Thing::setup), but it requires tying Thing::, and only works if setup takes no arguments. I want to basically use it as a normal function call.

[kioba]

Dart has a cascade notation with the .. operator. I am not sure if this is useful but it basically reduces the apply to an operator.
The only problem with replacing functions with operators is after a while everyone wants their own operator. there are languages which supports creating your own but for a newcomer it is hard to understand without codebase specific knowledge.
I agree with you, sometimes it would be comfortable to have a cascade operator or add your own but I read somewhere that the Kotlin team decided to avoid such for better readability.

[karelpeeters]

I do this often as well, especially in functions without a body to avoid introducing a tmp variable, but I don't think any of the proposed syntax in this thread is actually an improvement.

[kioba]

@karelpeeters do you have a preference for syntax?

[Ruckus]

@kioba Good points indeed

[karelpeeters]

I can't think of any better idea myself either, honestly I think apply is fine as-is.

[Hullaballoonatic]

i think similar to how you can do the same thing in java, double curly brackets could work

Foo() {{ 
    //things 
}}

[Hullaballoonatic]

in current version, you can also just do this:

class Foo(var bar: Int = 0) {
    constructor(op: Foo.() -> Unit) : this() {
        op()
    }
}

val foo = Foo {
    bar++
    println(this)
    // etc
}

[karelpeeters]

And that's the problem, it's ambiguous with a lambda parameter that returns another lambda.

[arocnies]

Would this function like DartLang's .. call? I don't mind Dart's syntax for it, but personally I prefer excluding it from the language in favor of apply