Dave Leeds on Kotlin - typealias.com

When you’re on hold during a phone call, you might also check your email.

Thanks to structured concurrency, there are a lot of concerns that we don’t have to handle manually when working with Kotlin coroutines.

We’ve seen how we can implement interfaces and extend classes to create subtypes.

All the way back in Chapter 8, when we introduced collections, we saw our first generic type: List<String> … then we saw more generics in Chapter 9 when we looked at the Pair and Map classes.

In real life, when we decide to do something, we primarily think in terms of a successful experience.

In Chapter 5, we saw how limiting our options can be a good thing.

At the end of the last chapter, we saw how all objects in Kotlin inherit three functions from an open class called Any.

In Chapter 12, we saw how we could use interfaces to create subtypes, and in the last chapter, we saw how we could use delegation with interfaces in order to share general code among specific classes.

Back in Chapter 2, we introduced functions as a way to prevent us from duplicating expressions.

Ever since Chapter 1, we’ve used a variety of built-in Kotlin types, like Int, String, and Boolean.

In the last chapter, we learned how to create extension functions, which can be called using dot notation.

Kotlin extensions can be used to add new functions and properties to existing classes—even to classes that you didn’t write!

In the last chapter, we saw how collections, such as lists and sets, can be used to do things that couldn’t be done easily with separate, individual variables.

So far, we’ve only worked with variables as individual values.

As we’ve seen, functions are a basic building block of Kotlin code.

So far in this book, every time that we created a variable, whether it was a String, an Int, or a Boolean, we assigned a value to it.

In the last chapter, we created our very own type, called Circle, using a feature in Kotlin called a class.

One core concept in Kotlin is a class, which allows you to combine variables and functions into a single unit.

In Chapter 1, we learned about a variety of types in Kotlin, such as Double, String, and Boolean.

In real life, we do different things depending on the circumstances.

In the last chapter, we wrote some Kotlin code to calculate the circumference of individual circles.

So you want to be a Kotlin developer?

One of the most common questions I get about Kotlin’s sequences is this: “When should I use sequences, and when should I use normal collections?”

Sequences are a fantastic way to process collections of data in a way that can perform better than the standard collection operations, as we saw in the previous article, Kotlin Sequences: An Illustrated Guide.

You’ve probably come across Kotlin’s sequences at one time or another.

In the last article, we discovered how Kotlin’s inline classes feature allows us to “create the data types that we want without giving up the performance that we need.”

Whether you’re writing massive data-chomping processes that run in the cloud, or mobile apps that run on low-powered cell phones, most of us want our code to run fast.

Heads Up This article was written waaaay back in 2018 when the current version of Kotlin was 1.2.60.

If you’ve ever had trouble remembering the difference between parameters and arguments, today’s article is for you!

Have you ever had a conversation like this?

Have you ever wondered how star-projections work?

Have you ever wondered why generic variance works like it does?

Generics can often seem confusing.

An out-projection is a kind of type projection that makes a generic covariant, but also causes any functions that accept the type parameter to be unusable in that context.

An in-projection is a kind of type projection that makes a generic contravariant, but also causes any functions that return the type parameter to return it as a more abstract type.

Declaration-Site Variance is variance that is specified at the point where the generic is defined – for example, in the definition of the class, interface, function, or extension property.

A type argument is a specific type, specified by the calling code, that a generic will use in place of a type parameter.

A type parameter is a placeholder for an actual type, which gets specified by the code that’s using the generic.

A type projection is a type that has been limited in certain ways in order to gain variance characteristics.

A variance annotation is a modifier applied to a type parameter or type argument of a generic, in order to declare its variance.

When dealing with simple classes, subtyping is straightforward.

Most of the time, subtyping is intuitive.

On the surface, subtypes seem straightforward.

Let’s think for a moment about everything that you can do with a class name in Kotlin - think of all the cases where you literally type out the name of a class in your source code.

Reified type parameters are type parameters that retain more characteristics of actual types than normal type parameters do.

Kotlin allows you to constrain a type parameter on a generic when you declare it, limiting the range of types that it can accept.

Overview Type parameter constraints allow you to limit the types that can be accepted as a type argument to an upper bound, giving you the ability to invoke functions and properties on an object while preserving the type.

Overview Generics allow you to create interfaces, classes, functions, and extension properties that can work with a “fill-in-the-blank” type, where the calling code can choose the type that should be used.

Overview Generic functions are functions that accept a type parameter, which allows different call sites to pass different types, without sacrificing type safety.

In Kotlin’s standard library, the Standard.kt file contains a number of scope functions that put a receiver object into a new scope as either this or as an argument (e.g., it).