TS тоже вполне мог бы это понимать

а что декоратор тогда может поменять?)

onlyUpdateFromKeys

в общем, дело в спеке

TS тоже вполне мог бы это понимать

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

но он не даёт

так декоратор ж обязательно мутирует, а не возвращает новое

там return тип вообще без разницы

по моему может и возвращать

если я не ошибаюсь

так декоратор ж обязательно мутирует, а не возвращает новое

вооот

надо проверить

вдруг захочется декоратору поменять поведение конструктора

хотя я не уверен

надо читать спеку, которая еще нигде не заимплеменчена и будет меняться)

уже че-то долго тянут

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

оно ж хоки возвращает, а не мутирует компонент

?

почему бы просто не юзать вызов функций?)

и тогда все начинает работать

тс не может в оверлоад функции с литералами?

может

но имплементация должна поддерживать оба варианта

ну

у меня declare тут

https://www.typescriptlang.org/play/#src=declare%20function%20qq(p%3A%20%22myParam1%22)%3A%20void%3B%0D%0Adeclare%20function%20qq(p%3A%20%22myParam2%22)%3A%20void%3B%0D%0A%0D%0A%0D%0Aqq('myParam1')

странно, тут не ругается

лол

оно записывается по другому же

https://www.typescriptlang.org/play/#src=%0D%0Aconst%20f%3A%20Foo%20%3D%20()%20%3D%3E%20%7B%7D%0D%0A%0D%0Atype%20Foo%20%3D%20%7B%0D%0A%20%20%20%20(a%3A%20%22foo%22)%3A%20string%2C%0D%0A%20%20%20%20(a%3A%20%22bar%22)%3A%20number%2C%0D%0A%7D%0D%0A%0D%0A%0D%0Aconst%20d%20%3D%20f(%22foo%22)%0D%0A%0D%0A%0D%0A

странно, тут не ругается

как)

аа

он ошибку не там показывает)

дело в объекте походу

дело в шляпе

https://github.com/Microsoft/TypeScript/pull/18654 ?

Пусть введут уже синтаксис для ко и контравариантов

Костыли

жесть какая

да, на весь проект переключать неудобно будет

I don't think anyone wants to see explicit bivariant or contravariant modifiers, or cryptic + and - annotations

Ееее

привет скала?

Methods are excluded specifically to ensure generic classes and interfaces (such as Array<T>) continue to mostly relate covariantly. The impact of strictly checking methods would be a much bigger breaking change as a large number of generic types would become invariant (even so, we may continue to explore this stricter mode). Еще и неоднородность появляется

привет скала?

привет флоу

Лучше бы добавили + и -, чем делали флаги

Почему import('test') может компилироваться в Promise.resolve().then(function () { return require('test'); }) а не в new Promise(function (resolve_1, reject_1) { require(['test'], resolve_1, reject_1); })

Лучше бы уже сделали один флаг --do-what-flow-does, а не кучу мелких

Ну они все в --strict добавляют, просто до flow все равно еще далеко

лол

https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Namespaces%20and%20Modules.md#needless-namespacing

Почему import('test') может компилироваться в Promise.resolve().then(function () { return require('test'); }) а не в new Promise(function (resolve_1, reject_1) { require(['test'], resolve_1, reject_1); })

потому что второй вариант неправильный

потому что второй вариант неправильный

второй вариант выдает плейграунд с официально сайта

Там AMD модули значит

https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Namespaces%20and%20Modules.md#needless-namespacing

норм

А как вы в TS пишете выражения вида (0, this.function)()?

Ругается на error TS2695: Left side of comma operator is unused and has no side effects.

(0 as any, this.function)() прям девиз ts: просто добавь any

А как вы в TS пишете выражения вида (0, this.function)()?

зачем такое писать?

(0 as any, this.function)() прям девиз ts: просто добавь any

ыхыхы

А как вы в TS пишете выражения вида (0, this.function)()?

Нет, серьезно, зачем?

зачем такое писать?

более быстрый (где-то я такое слышал) аналог this.function.call(void 0)

ну вообще похоже на то, что вызовется действительно без контекста

исправил мессагу

более быстрый (где-то я такое слышал) аналог this.function.call(void 0)

лучше писать явно

исправил мессагу

Да, напутал с null | undefined

но это дичь

лучше писать явно

Это уже другой вопрос

но это дичь

Внутри библиотеки почему бы и нет

@aquahawk думаю меня поддержит :)

Внутри библиотеки почему бы и нет

какая разница внутри чего?

Внутри библиотеки почему бы и нет

если в либе это будет результатом компиляции, то ок но в исходниках такое, ещё и в тс, как-то дерьмово

Не ну можно конечно написать так: const fn = this.function fn()

если в либе это будет результатом компиляции, то ок но в исходниках такое, ещё и в тс, как-то дерьмово

+1

Но там есть всякие неявные контексты, я вот не уверен что там в this не будет window

(0 as any, this.function)() прям девиз ts: просто добавь any

о да, точно

Но там есть всякие неявные контексты, я вот не уверен что там в this не будет window

не будет window?

Это вообще как в 2к17?

это ж надо use strict отключать принудительно

если это вообще возможно

в сборщике/компиляторе, я имею ввиду

Но там есть всякие неявные контексты, я вот не уверен что там в this не будет window

проще выучить, как this работает, чем говорить СТРАННОЕ про «неявные контексты»

проще выучить, как this работает, чем говорить СТРАННОЕ про «неявные контексты»

Ой ну простите

Да, через отдельную переменную лучше

А как вы в TS пишете выражения вида (0, this.function)()?

нет не поддержу, я такое не пишу