Підсумки

Висновки

Параметр типу робить тип значення частиною контракту класу чи функції, і компілятор перевіряє цей контракт без приведень. Верхні межі, зокрема T : Comparable<T> і кілька меж у where, описують потрібні алгоритму можливості, а не конкретні класи. За замовчуванням параметр може бути nullable, тому зміст null визначають до вибору межі T : Any або T & Any. Звичайний узагальнений клас інваріантний: підтип елемента не робить контейнер підтипом, якщо через нього можна записувати. Позначки out і in на місці оголошення та проєкції на місці використання відкривають лише безпечний напрям доступу, а Box<*> позначає невідомий, але узгоджений аргумент. Через стирання типів на JVM перевірка is T можлива лише для reified-параметра inline-функції, і вона не перевіряє вмісту вкладених узагальнень. Sealed-результати з Nothing виражають успіх і помилку, тоді як typealias лише дає інше ім’я тому самому типу. Контракт узагальненого API перевіряють і виконуваними прикладами, і окремими прикладами, які не повинні компілюватися.

Питання для самоперевірки

1. Чим параметр типу відрізняється від аргументу типу?
2. Яка верхня межа використовується за замовчуванням?
3. Коли T : Any краще за nullable-параметр?
4. Що означає T & Any?
5. Чому контейнер із читанням і записом інваріантний?
6. У якому напрямку можна присвоїти Source<Cat>?
7. Чому споживач тварин придатний для котів?
8. Чим проєкція відрізняється від оголошеної варіантності?
9. Чому Box<*> не дорівнює Box<Any?>?
10. Які перевірки не дозволяє стирання типів?
11. Чого reified не гарантує для вкладених колекцій?
12. Чому псевдонім не створює новий предметний тип?

Корисні посилання

• https://kotlinlang.org/docs/generics.html.
• https://kotlinlang.org/docs/inline-functions.html.
• https://kotlinlang.org/docs/type-aliases.html.
• https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.reflect/type-of.html.