@dh44t: thanks for the link

I found a perfect use-case for

lateinit

in a pure kotlin code: http://stackoverflow.com/questions/34217789/how-to-reference-other-views-in-anko-dsl The thing that may be used here is weakening the compiler checking. But

lateinit

also implies an open java field (useful for reflection).

Q: Don't you think that this is mixing two concepts into one: late-initialization and initialization-via-reflection?

Q2: Can someone explain to me how

lateinit val

is going to be implemented?

possible proposal: to remove the implied java-field from

lateinit var

semantic; instead of that to have

@jvmField lateinit var

Sorry, Is three anything wrong with my questions? Should i rephrase them?

Kotlin devs may be in a far-away timezone, so I usually wait about 24 hours before bumping 😉 (sorry, don't have an answer to your question(s) though)

I created an issue for the question I had earlier (https://kotlinlang.slack.com/archives/language-proposals/p1449612957000187): https://youtrack.jetbrains.com/issue/KT-10403

@voddan: there is a lot of chatter around here, sometimes we miss things. Just ping us if we seem to miss something.

@voddan:

Q: Don't you think that this is mixing two concepts into one: late-initialization and initialization-via-reflection?

It’s a philosophical question whether this is mixing or not, but I think that killing these two birds with one stone is a nice thing to do

Q2: Can someone explain to me how

lateinit val

is going to be implemented?

It may well be never implemented, or never expose a Java field (while a

var

would expose it). Asking all DI clients to write

@jvmField lateinit var

is too `public static void main`y for us

@abreslav: ok, thanks, I see your point. The question of the mixing is not so philosophical, but very practical because of me and other people having trouble understanding the concept, and then explaining it to others

if you like nature analogies, I see

lateinit var

in its current state as a two-headed bird. Rather scary than cute ))

I don’t think we can help it simple smile

i think you do. May I create a ticket, so you could put it "to be considered" ?

Of course you may create a ticket, but so far I rather see it under “As Designed"

Details welcome, maybe I’m missing something

nods

my only big complaint about lateinit is that it’s a bit of an end-run around nullability in the type system but it’s a necessary wart, i think.

It's a more performant version of

Delegates.notNull

which has a clear contract. I don't think it undermines the nullability.

This probably isn't the right channel for this, but will we ever see a documented API for creating custom compile-time synthethic properties, much like kotlin android extensions? I think the demand for this would be low since it's highly technical, but just out of curiousity

this is possible, yes

oh, but they could be really interesting for ORM/ODM libraries...

examples?

I mean “it is possible that we will provide such a documented API in the future"

AST transformations! 😍

<!here|@here>: Hello everybody, I’d like to share some information about

async/await

and Kotlin. On the bright side: we are going to support

async/await

in one of the future versions of the language. On the difficult side: to be able to do it later, we'd better reserve the syntax now, and this means that

async

becomes a keyword. In particular, libraries (including Kovenant and Anko) that currently have their own functions names

async

will not be able to use them as

async { … }

, which is unfortunate. A workaround for these libraries would be saying

async() { … }

instead.

👍

well it's for a very good cause

A small price to pay

what will such

async

keyword be doing? as android dev i'm particularly interested in android implementation. will

async

spawn a new thread on jvm, use executor or maybe android's asynctask ?