I believe it would be more appropriate to post this here, but is there any actual problem with utili...

# getting-started

[John Guerra]

I believe it would be more appropriate to post this here, but is there any actual problem with utilizing Units? I've heard mixed stuff about them and how you should use open brackets rather than utilizing a Unit

For example

override fun onEnable() {
  plugin.server.onlinePlayers.forEach(::join)
}

Rather than

override fun onEnable() = plugin.server.onlinePlayers.forEach(::join)

[nanodeath]

I think it'd be clearer to say onEnable(): Unit = ... if you go with the latter

[nanodeath]

it is strictly preference...I don't think there's much difference either way. I do use expression syntax almost whenever I can though.

[John Guerra]

Yeah, my apologies. I should of said it more correctly and labeled it as an "Expression body". I figured it was preference. Personally, I find using it nicer in some scenarios, though in others I find utilizing a block body nicer to look at.

I thought there'd possibly be some form of benefit otherwise.

[Ruckus]

Most of the arguments I've seen appear to boil down to how you interpret the meaning of fun ... =. From my experience, those who just view it as short hand / sugar tend to be okay with it, whereas those who view it as a form of assignment (semantically of course, not literally) tend to take issue. I'm not sure the reasoning or if I've just got some severe sample bias.

[nanodeath]

when I was just learning Kotlin I got really confused between val ... = and fun ... =

[John Guerra]

Makes sense honestly. I can see why people would view it the way they do (Those who take issue of it). Personally, I never viewed it that way, but at the same time, everyone interprets things differently at times.

[John Guerra]

@nanodeath, same. Don't get me wrong, still learning. Still pretty fresh to the language, but I think I am getting the hand of it. I find developing in Kotlin much nicer.

[Jakub Pi]

The only issue I've seen is that if you use the bracket syntax but don't make the return type explicit as with : Unit then in some rare cases, the type inference may fail. I've seen it happen once or twice in real code (though probably not with Unit as the return type - some heavy generics involved).