@User uploaded a file: Untitled and commented: Excerpt for

build.gradle

with Kotlin 1.1-M01 and kotlinx.coroutines from Bintray for the lazy.

you can also do

repositories { jcenter() }

Awesome!

dumping bugs while playing around with type aliases: https://youtrack.jetbrains.com/issue/KT-13183

I though

lateinit

in functions will be in 1.1, but didn’t find it in

1.1-M01

😞 Any plans for that? Would really help writing tests with Spek.

is there a proposal for it?

@Eugenio: I can't find anything for

lateinit

in KEEP. https://github.com/Kotlin/KEEP/search?q=lateinit

https://youtrack.jetbrains.com/issue/KT-13204 is pretty annoying, I must say

@kirillrakhman: Sorry, I'm just back from vacation. Will take a look. Still, some more reasonable repro would be nice to have.

thanks, I didn't mean to rush

I'll try to create a repro

@dmitry.petrov: I created a repro https://github.com/cypressious/KotlinTypeAliasIcBug

thanks!

Sorry JB, but

typealias

looks useless 😞 *

typealias UserId = String

allows me call all

String

functions on

UserId

* Extension properties and functions for typealiases available on original type Would be great if

typealias

will be converted to original type only at last step — bytecode emission and will be treat as a separate virtual type before that, preventing things mentioned above ^ as compilation errors.

Yes, it is intentional. Type aliases do not introduce new types.

And I think that's great for a lot of use cases!

I know, but… idk what to use them for at the moment. Initially I though that the only part of it would be that you can assign val of original type to typealias, which ~ok, but things ^ make whole concept kind of useless for production

The only thing that bugs me is that if you define a function in a class with a type alias, when you override it it will have the base type instead and you have to manually replace the types :/

You can use type aliases to turn generic classes into domain types

Now for example you'd wrap a

String

into a, say,

UserId

. But you don't need to, in many cases; just create a typealias.

1. Java interop. 2. Value classes (1.2+). 3. Whole lot of issues with types which are not classes in current type system. ... N. They are called "type aliases", not "types", for a reason. But who really cares 🙂

Basically, when types are classes (including interfaces, objects), all that complex stuff that happens with generics with declaration-site variance is considerably simpler.

Type aliases as they are designed in 1.1 are sort a like macros on type projections.

@dmitry.petrov: do you know if this is the intended behaviour or it will be fixed?

You mean, override with Ctrl-O in IDE (looks like a bug), or... ?

I guess a bug or just not implemented yet?

and yes, override through the IDE

Yep, some IDE features do not support type aliases yet. Still, please, file a bug in YT.

1. Java interop won’t be broken if resulting bytecode will use original type 2. Yup, waiting 3. Ok… … N. Right. @dmitry.petrov Then maybe better deprecate adding extension functions and properties to typealiases to not break user expectation?