Ok, stupid idea that I already have a counter-argu...

# language-proposals

[eduardog3000]

Ok, stupid idea that I already have a counter-argument for:
Implicit null return, if a function's type is nullable, reaching the end of the function without a return should implicitly return null.
Problems:
• Unit is currently the only implicit method return, adding another might make it confusing.
• Only works for functions with explicit returns, idk if Kotlin has another feature with the same restriction (Nothing maybe?).
• What happens if a function returns Unit?
• Is this even useful?

Untitled

[Quy D X Nguyen]

Instead of erroring when you forget a return, now null is returned and you get nullpointers (or incorrect code in Kotlin) down the line

[eduardog3000]

Only if the function return is defined to be nullable.
But that is definitely a problem that could cause confusion, thanks.

[eduardog3000]

I hadn't thought about it from that perspective.

[jimn]

it.takeIf{bool}

[Dico]

Problem with takeIf is that the receiver is always computed. It would be cool to have some kind of Boolean.let {} function for this.

[Dico]

I often find myself writing if (bool) expression else null

[jimn]

the usecase where i can imagine that a value predicate is an avoidable computation is a config-check usecase.

[jimn]

you can make config idemotent by lazy

[gildor]

if/else is the cleanest, readable and most flexible way than any let/apply blocks imo

[Dico]

That's not to say that there shouldn't be an alternative for this common use case

[Dico]

Which might read better of chained, to give an example.

[gildor]

Alternative solution with custom syntax looks as huge overkill for this use case imo

Implicit return type as it proposed is very bad solution imo. It will be very easy to get some exception when you have more than 1 line in function, because every branch without expression becomes implicit return null