Type Projections... and why they work!

[@typealias]

Hey all - there's been lots of great interest in the idea of doing some livestreams, so I'm working on that! ✨ If you're interested in it and you haven't already done so, take 60 seconds to fill out this survey ( www.surveymonkey.com/r/5MSRNDC ) to let me know what kinds of stuff you'd be interested in, and what times would work best for you. Thanks!

[@sevbanthebuyer]

Hey Dave, link is broken for your information!

[@typealias]

Ah, thanks for letting me know, Sevban! Looks like KZbin got confused and thought the closing parenthesis was part of the link... Anyway, it's all fixed up now - thanks again! 👍

[@Никита-ж5с1ч]

Best explanation of Kotlin generics I've ever seen. Thank you for your work man, please keep going 👨‍💻

[@enossalar8837]

your channel is a gem

[@typealias]

Thanks so much, Enos! I appreciate that!

[@BaptistPiano]

I tend to believe more in functional programming and interfaces rather than subtyping, but this is an interesting problem for OO languages, and an interesting solution. Awesome video.

[@westforduk]

This was really insightful - thanks Dave!

[@typealias]

Hey, thanks so much! PS - Love the Poirot avatar! I'm a big Agatha Christie fan.

[@westforduk]

@@typealiasmost kind of you to say mon ami ;)

[@manjaro675]

I'm currently switching back to Native Android from Flutter and your videos really help out a lot. Thanks!

[@typealias]

That's great to hear! I'm glad they're helpful!

[@tanveerabbas26]

Your content is awesome.

[@typealias]

Ah, thanks so much! I'm glad you like it!

[@danielgibby5402]

I thought that the word projection in Kotlin meant the definition of projection which means looking into the future. e.g. projection: an estimate or forecast of a future situation. So that means that a projection of a variable is telling the compiler that you expect all future values of the variable to be of a certain type.

[@typealias]

Ah, interesting - I never thought about how that particular definition of projection could apply to it! For programming, the term is rooted in mathematics, and the idea is basically that you're selecting certain parts of an existing type to project onto a new type. So for an out-projection, the covariant parts of the type (i.e., the ones where the type param is in the out-position) are technically the parts that are "projected" onto the new type, and the remaining parts are hidden or manipulated in some way (e.g., in Kotlin, manipulated so the types have the required variance).

[@mikhailbarash4041]

Thank you for the amazing video! 💯 At 4:15, should that rather be “covariance”, and and 5:18, should that be “contravariance”?

[@typealias]

Thanks so much! I'm glad you liked it! I can definitely see how I could have explained those parts more thoroughly. In order for anything to be a subtype of another type, there must be _both_ contravariance _and_ covariance - there must be contravariance for each parameter type, and there must be covariance for each return type. By using `out` on a type argument, the type will _naturally_ have covariance with its return types that use T (which is why we're used to associating `out` with covariance). But something still has to happen to ensure that it has contravariance with its parameter types that use T. Kotlin handles this by replacing those types with `Nothing`. So at 4:15, I'm referring to how `Nothing` establishes that contravariance for the parameter type (rather than the covariance that exists naturally on the return type). Does that help to explain it better?

[@Mister_Pine]

Why does an in projection modify the return types to `Any?`? Wouldn't the upper bound, in your example `Product`, work, too? Just as in a star projection?

[@typealias]

There's a long-standing ticket about that here: youtrack.jetbrains.com/issue/KT-11273/Make-in-T-in-out-position-equivalent-to-upper-bound-of-T-rather-than-Any. There aren't any comments indicating a reason for the difference, and I can't think of any reason it would cause problems from a type-safety perspective. Here's hoping this ticket will get resolved sometime after Kotlin 2.0 comes out!

[@Kubkochan]

​@@typealiasseems like it should be fixed in 2.0.0 betas

[@Mister_Pine]

Interesting, thanks for your Answer!

[@dk6024]

Rather than 'supertype' do you mean 'assignable'?

[@typealias]

The Kotlin language specification refers to `Any?` as the "unified supertype for all types in Kotlin", and I tend to stick with that phrasing as well - but it does bring the effect of assignability, so you could say that, too!

[@dk6024]

Help a Kotlin pregrammer find a job.

[@typealias]

Ah, sorry if you're having trouble finding work! I'm sure you're not the only one - I'll put some thought into ways I might be able to help the community with this.