Pipe-forward operator |>

Language Design
53

not adding features that improve the language make it either stagnate (-> java) or just stay incredibly limited forever (-> go).

you CAN do this using extension functions, but you should always think about expressivity more than just about “can you do that”. creating an extension function for something that is in no way actually either a) a transformation of the receiver, b) an action the receiver does, c) a check for something about the receiver - imo is a bad idea. There is also the case that there are many methods of other classes you might want to include in such a chain.g

imagine seeing code like this:

val parseableData = "    a: 12, b: 13, c: 'asdf'"
websocketConnection.send(
  someSerializer(
    serializationConfigArgument, 
    myDemoParser.parseString(parseableData.trim()).doSomeStuff()
  )
)

vs

val parseableData = "    a: 12, b: 13, c: 'asdf'"
parseableData.trim() 
  |> myDemoParser.parseString 
  |> it.doSomeStuff() 
  |> someSerializer(serializationConfigArgument, it) 
  |> websocketConnection.send

vs your proposed way, which looks realllllly strange:

val parseableData = "   a: 12, b: 13, c: 'asdf'"
parseableData.trim()
  .parseUsing(myDemoParser)
  .doSomeStuff()
  .serializeWith(someSerializer, serializationConfigArgument)
  .sendToWebsocketConnection(websocketConnection)

The reason this last one looks so strange is that sendToWebsocketConnection is NEVER a method that should be on String, no matter the circumstances. While it does read simmilar to the second one, it does not convey the actual relationship between the classes in an expressive manner.

And that is imo what kotlin is so extremely good at. Expressivity.
So a feature (which is, btw, also proposed for arguably the most popular language, JS, and will most likely get implemented into the JS standard in the not so distant future) that does help readability, expressivity and conciseness should at least be very well considered.

Kotlin is not Go, where features are the devil and language-complexity is something to avoid by all means. Sure, kotlin should stay approachable and not include overly complex features (implicit conversions come to mind), but this is not one of those. kotlin does already have an incredibly large feature-set for such an approachable language. adding features is not a bad thing. Staying verbose and unexpressive however, is.

4 Likes