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!
Ah, thanks for letting me know, Sevban! Looks like TH-cam got confused and thought the closing parenthesis was part of the link... Anyway, it's all fixed up now - thanks again! 👍
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?
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.
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?
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!
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.
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).
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!
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.
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!
Hey Dave, link is broken for your information!
Ah, thanks for letting me know, Sevban! Looks like TH-cam got confused and thought the closing parenthesis was part of the link... Anyway, it's all fixed up now - thanks again! 👍
Best explanation of Kotlin generics I've ever seen. Thank you for your work man, please keep going 👨💻
from simple to deep, a very concise but profound and informative explanation. Thank you a million times Deve! great job!
your channel is a gem
Thanks so much, Enos! I appreciate that!
Thank you for the amazing video! 💯 At 4:15, should that rather be “covariance”, and and 5:18, should that be “contravariance”?
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?
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.
I'm currently switching back to Native Android from Flutter and your videos really help out a lot. Thanks!
That's great to hear! I'm glad they're helpful!
This was really insightful - thanks Dave!
Hey, thanks so much!
PS - Love the Poirot avatar! I'm a big Agatha Christie fan.
@@typealiasmost kind of you to say mon ami ;)
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?
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!
@@typealiasseems like it should be fixed in 2.0.0 betas
Interesting, thanks for your Answer!
Your content is awesome.
Ah, thanks so much! I'm glad you like it!
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.
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).
Rather than 'supertype' do you mean 'assignable'?
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!
Help a Kotlin pregrammer find a job.
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.