чет тупанул)

Если ты его укажешь, то тайпскрипт не сможет его нормально проверить. То есть по сути это будет кастинг любого типа к тому, который ты указываешь

ну, если ts знает, что в этом объекте есть какой-то value, который не подходит под тип, то логичнее тогда и кинуть ошибку

Он не знает

почему же, если там указано что-то типа {[s: string]: Value}

Потому что это указывает на доступ по индексу, но не по итератору

Итератор вы можете определить через Symbol.iterator и возвращать оттуда что душе угодно

for...of использует итератор

Так понятнее?

и в чем проблема?

The left-hand side of a 'for...of' statement cannot use a type annotation это вот еще почему? типа активное автоопределение?

ну это объяснение явно не причем

Вполне логичное объяснение

Итератор вы можете определить через Symbol.iterator и возвращать оттуда что душе угодно

так а Symbol.Iterator разве string?

Нет

объект с итератором не подойдет под этот тип

почему же, если там указано что-то типа {[s: string]: Value}

не вижу логики. Очевидно, что в левой части нельзя ставить аннотацию, потому что ее всегда можно вывести из правой части

почему всегда ее можно вывести?

эмм, но это очевидно так. Если справа Array<T>, то слева T

с такой логикой у const тоже не должно быть аннотаций)

а если any?

да хз, это же вы тайпскрипт используете

почему же, если там указано что-то типа {[s: string]: Value}

я понял. Вы думаете, что это показывает какие типы могут быть в объекте, но на самом деле, это показывает что может быть аргументом в операторе индекса ([]) и что результатом этого оператора

во Flow можно

)

при этом итерировать объект можно независимо от оператора индекса

я понял. Вы думаете, что это показывает какие типы могут быть в объекте, но на самом деле, это показывает что может быть аргументом в операторе индекса ([]) и что результатом этого оператора

да, показывает аргумент оператора, при этом иное обращение к объект, кроме как [] запрещено

итого, что может быть в объекте?

во Flow можно

что вполне логично

итого, что может быть в объекте?

да пофигу что там может быть. Он может вообще не поддерживать оператор индекса, но поддерживать итератор. Это ортогональные операции

я все равно не понимаю, в чем разница между let a of someHell и например let a = someOtherHell()

почему в одном случае нельзя, а в другом можно)

Читай про итераторы в ООП

Object.values и должен давать Iterable<any>

ANY

вмсмысле Iterator

да боже ж ты мой! да! может быть любой итератор, который вернет любую фигню. и я хочу, чтобы в этом цикле мне из итератора приходила строка, например. и плевать, что тайпскрипт при компиляции не проверит, точно ли итератор возвращает строку. он хотя бы проверит, что внутри у меня используется точно строка

хотя для {[s: string]: Value} можно сделать исключение

да и для итераторов можно сделать обработку ситуаций. предполагать, что там T из { [s: string]: T }, а если там что-то хитрее, то сам укажешь

да и для итераторов можно сделать обработку ситуаций. предполагать, что там T из { [s: string]: T }, а если там что-то хитрее, то сам укажешь

типа того

да и для итераторов можно сделать обработку ситуаций. предполагать, что там T из { [s: string]: T }, а если там что-то хитрее, то сам укажешь

Но ведь нельзя это предполагать ?

Но ведь нельзя это предполагать ?

если тип именно такой, то можно, если нет, тогда нужно указывать явно

оставлять any совсем отстойное поведение

Но ведь нельзя это предполагать ?

во-первых, можно, почему нет? всегда можно откатиться к any

а итератор, наверное, в интерфейсе можно определить. тут не уверен, ну да не важно

Лол

проблема в том, что я ХОЧУ указать ТИП переменной, в которую кто-то там будет что-то пихать

"Пара слов о том, почему система типов в typescript — это боль"

плевать на итератор и прочее

Ну так ниже в теле цикла сделай ей каст в нужный тип

почему при декомпозиции параметров возникают проблемы с TS — понятно

а здесь — непонятно

Ну так ниже в теле цикла сделай ей каст в нужный тип

что не так в записи for (let a: string of o)?

вот мой вопрос, который за эти часы не изменился

все норм, если o - Iterable<string>

не норм

The left-hand side of a 'for...of' statement cannot use a type annotation это вот еще почему? типа активное автоопределение?

для тайпскрипта не норм

потому что ts - говно

а по сути - норм

Потому что этот тип никак нельзя вывести на этапе парсинга тайпскрипта. Так понятнее?

почему нельзя? можно

но здесь речь не о выводе типа, а о том чтобы его руками указать

это просто не должно быть нужно (если справа не Iterable<any>)

Потому что этот тип никак нельзя вывести на этапе парсинга тайпскрипта. Так понятнее?

тип входящих данных никак нельзя вывести. и тем не менее мы указываем их структуру. что за бредовый аргумент?

и в 99% вывести можно

а справа у меня Object.values, который тоже идиот

потому что для типов без указания индексного параметра он откатывается к any

а указание индексного параметра превращает объект со строгими ключами в хэш, для которого любой ключ подходит

а что еще там может быть?

где там?

> @hlomzik потому что для типов без указания индексного параметра он откатывается к any

там где any

values<T>(o: { [s: string]: T }): T[]; values(o: any): any[];

вот определения из lib.es2017.object.d.ts

ну все верно

лучше сделать вроде нечего

проработать работу с объектами

как, например?

а указание индексного параметра превращает объект со строгими ключами в хэш, для которого любой ключ подходит

ну да, у типа иметь операторы для получения полей

в итоге для объекта типа { required: string[], optional: string[] } нельзя применять методы, принимающие объект как хэш

естественно

это в этом же суть хэшей

в чем?

Object.values пригоден только для абстрактных хэшей, в которых может быть тысяча произвольных полей?

вам можно, а вам нельзя?)

он применим и объектам, просто ничего кроме any гарантировать нельзя

я могу гарантировать, что в этом объекте всего 10 полей, и у них у всех такой вот тип :)

ладно, можно подумать еще над структурой

но нет способа описать это

проблема мелкая

но нет способа описать это

вот в этом проблема, а гарантировать вполне

кажется, есть :) сейчас попробую

https://github.com/Microsoft/TypeScript/issues/3500

через enum

гарантировать можно, только если можно это описать

вот вам ответ от авторов

если у нас класс с 2 полями string и 1 number, то вполне логично на values кидать [string, string, number]