Но сама идея как работает деструктуризация - не является безопасной сама в себе. Я куда угодно могу написать сколько угодно componentN с любыми типами. Даже сейчас же есть в стандартной либе:

val (first, second, third) = list , который спокойно может уронить в рантайме.

Поэтому и предлагал для позиционных сделать фолбек до get(Int) там, где это имеет смысл (например в листах тех же) и в именных как основной путь - на основе пропертей и фолбек до get(String), там где это уместно.

@noraltavir всё таки есть идеи как это делать без componentName, но при этом хорошо для дата классов, мне интересно?

Да забудьте вы про листы. Говорим только про дата классы или что-то у чего руками прописаны componentN

Не знаю, я исходно сказал, что сложно. Вон Ильмир то же самое сказал.

Так в нормальных дата классах просто есть проперти, там просто срабатывает в моей идее именная деструктуризация без фолбека.

В общем, товарищи, пишите пропозалы в ютреке (теперь все там).

// file1.kt
data class User(val id: Int, val name: String)

// file2.kt
val (id, name) = user

// changes in code

// file1.kt 
data class User(val id: Int, val cityName: String, val name: String)

// file2.kt: Oops

Текущая деструкторизация для data классов вредна чуть более чем полностью)

аа, вы хотите, чтобы все классы можно было декструктуризовать так?

class A {
   val foo = "text"
   val bar = 0
}

val { foo, bar } = A()
// foo: String, bar: Int

это интересно

Ну т.е. не прямо интересно, за это топят примерно все, кто хоть чуть-чуть кодили на свежем js, но да, такой подход будет побезопаснее, чем позиционный для обычных классов :)

// file1.kt
data class User(val id: Int, val name: String)

// file2.kt
val (id, name) = user

// changes in code

// file1.kt 
data class User(val id: Int, val cityName: String, val name: String)

// file2.kt: Oops

Это почему? Если классы менять от которых зависят другие классы, то логично, что что-то сломается
Плюс по идее этот код должен работать

Ну, вот с именным деструктурированием это не проблема (код компиляется, но логически стал неправильным, ибо у нас в name оказался cityName)

Не логично, понятно что так сделано, но не логично. Имена должны браться из класса, и проверяться что там есть такое имя и браться его тип

Он будет работать неправильно. Тут согласен

Как должно быть

1:

// file1.kt
data class User(val id: Int, val name: String)

// file2.kt
val (id, names) = user // compilation error

2:

// file1.kt
data class User(val id: Int, val name: String)

// file2.kt
val (id, name) = user

// changes in code

// file1.kt
data class User(val id: Int, val cityName: String, val name: String)

// file2.kt
val (id, name) = user
check(name == user.name) // Ok

За все время я один раз использовал деструкторизацию в реальном проекте, и скорее просто чтобы использовать, а не потому что нужно 🙂

val url = "/user/42”
val (_, id) = PathParser(url, “user”)

// file1.kt
data class User(val id: Int, val name: String)

// file2.kt
val (id, names) = user // compilation error

2, но оно не хуже того варианта, что сейчас в котлине, просто это разные варианты, кому как лучше

val url = "/user/42”
val (_, id) = PathParser(url, “user”)

Я её вообще ни разу не юзал)
Крутой спор

текущий вариант в data class делает его использование бесполезным

А, нет, было один раз, когда я key value из entry доставал

Оно в любом виде довольно бесполезно как по мне