@adinugroho: what about

lateinit

?

damn... slack didn't scroll. my message could be a bit late. sorry

from #C0B8Q383C: https://kotlinlang.slack.com/archives/stdlib/p1450359243000278

@ivan.morgillo: yeah agree with you.

@abreslav: my main feedback is you should probably give extra clarity around "kotlin 2.0" and in particular, promise not to do that for e.g. at least 5 years

if kotlin is gunning to be the de-facto upgrade from Java for enterprise shops (and I hope it is), then people will want to know that they don't end up in a Python 2/3 type situation where the community splits due to some parts being willing to pay upgrade costs and others not

Screen Shot 2015-12-17 at 3.11.00 PM.png

just now 👍

extra clarity around "kotlin 2.0" and in particular, promise not to do that for e.g. at least 5 years

even Java has a shorter release cycle

2.0 means "not compatible with 1.0"

java has never done a java 2.0 in this sense. even the latest version is technically 1.8

and Java not being updated fast enough is the reason why everybody wants to switch to another language

you are thinking of e.g. kotlin 1.1, 1.2, 1.3, 1.4 etc that would add features

@mikehearn: could you please post to forum instead? In Slack it will be gone really soon. Also Slack format is not very good for bigger posts and answers, that’s why we choose forum.

ok

@abreslav would that be possible to make RC after the holidays? I was going to do more kotlin at the free time, think it is the same for many others. Great opportunity if you want the final feedback

@voddan: we’ll see, but it’s likely that RC will be published after the NY holidays in Russia

Is there a Kotlin standard library function which calls System.exit, but returns Nothing instead of void/Unit?

@jshmrsn: I think they are equivalent. can you be more specific?

I found out through earlier questions I asked here that returning Nothing has the special meaning that the function will never return, which has implications on things like the nullability of the result of if expressions

I just hit a situation where I had something like

val foo = try { "foo" } catch { println("error!") System.exit(1) }

and Kotlin was saying foo was String?, not String, because of the catch case.

So I made my own

fun exit(status: Int): Nothing {
    System.exit(status)
    throw Exception("(this should never be seen)")
}

which solved my problem, but seemed like something that could be in the standard library

I see. well, I can't say 😕

@jshmrsn: It’s the “type safe builder pattern”, looks like you got a few links already, let me know if you have further questions. This is what enables clean syntaxes for DSL. Another example is Kobalt: http://beust.com/kobalt/home/index.html

Thanks, yeah I got pretty thorough education about it simple smile

As for “is it worth the extra syntax”, resounding yes from me obviously simple smile

This enables a Gradle-like syntax in Kotlin, 100% statically typed and just as pleasant to read

Yeah, when I asked the question, I had no idea it was connected to the DSL stuff. Was curious to find out what made it justified, and I was well convinced that it is

I think having a clear specification "from above" is a good idea, even if it doesn't cover all cases.