Являются ли аргументы типа в интерфейсах фактическим типом?

Question

Не думаю, что заголовок является лучшей формулировкой для этого вопроса, у меня есть интерфейс с двумя аргументами типа, и мне кажется, что я могу привести this в качестве обоих типов одновременно, см. Воспроизводимый пример:

interface BaseResult<S : BaseResult<S, E>, E : BaseResult<S, E>> {

    @Suppress("UNCHECKED_CAST")
    fun isSuccess(): Boolean {
        return try {
            val a = this as S //ClassCastException expected
            val b = this as E
            println(a) //com.BaseResultTest$ExampleResult$Error@17d10166
            println(b) //com.BaseResultTest$ExampleResult$Error@17d10166
            true
        } catch (e: Exception) {
            false
        }
    }
}

Тест:

class BaseResultTest {

    sealed class ExampleResult: BaseResult<ExampleResult.Success, ExampleResult.Error> {
        object Success: ExampleResult()
        object Error: ExampleResult()
    }

    @Test
    fun test() {
        val error = ExampleResult.Error
        assertEquals(error.isSuccess(), false)
    }
}

Я что-то упустил, или это ошибка в языке? Использование v1.3.61

Answer 1

Это тип стирания , который работает одинаково для всех обобщенных типов, а не только для интерфейсов. В этом случае оба приведения становятся эквивалентными as BaseResult<*, *>.

Kotlin имеет способ избежать этого , но только для параметров типа методов inline, а не классов или интерфейсов.

Answer 2

Это не столько ошибка в языке, сколько ошибка логики c автора. Хотя вы можете обозначать типы S и E, они по-прежнему похожи на Option, а его подтипы Some и None (для некоторых всегда указывается Option<_>, тогда как None всегда пусто.

Часть вашей проблемы здесь заключается в том, что вы не можете гарантировать подкласс типа S или E без явного объявления подтипов для этих случаев. Можно увидеть примеры этого в попытке реализовать Either, а также некоторые другие примеры , в том числе и о Либо .

Надеюсь, это поможет ответить на вопрос.