g
я может вообще хочу символьные атомик типы как в ts
var sas = "a" | "b"
var sas = "a" | "b"
Size: a a a
2021 May 24
f
ну макросы
f
и вперед
2021 May 25
G
Не знаю как макросами решать запрет на разные типы в разных ветках у одного поля
f
Ну вот тут "труъ" sum-types у которых таких проблем нет
f
Понятное дело
object.field тут нормально сделать не получится без flow-dependent typing, так как тип неизвестен все равно будет.f
Ну точнее здесь только по позициям, но можно заменить на именованные tuple и тогда всё будет нормально
G
Это все хорошо, но если большинство не будет это использовать, то смысла в этом нет
f
Это почти полностью взаимозаменяемо с кодом написанным на обычных вариантах. Просто чтобы получить поле разного типа вручную надо использовать
object.varField.actualFieldf
Надо только имя для
varField генерировать нормальное а не просто по индексу, но в остальном все решаемоG
Надо посмотреть сколько сериализаторов проверяют именованный это tuple, или нет, чтобы случайно не обработать varField как обычный список
f
Такое скорее всего никто не проверяет, это да. Но если сериализовать tuple поля просто как есть то мне кажется проблем не будет
G
Kind4(MyObject) развернется в varField: (MyObject,)?
f
да, должно работать так
f
Чем 50 строк которые я накидал в качестве примера
G
G
Ну с принятым RFC это как-то решится
f
для переиспользования полей?