to explain that, you mean function declaration w/ destructuring param needs {x}:{x:string} in TS.
-
-
Replying to @BrendanEich @lbljeffmo and
yes. As a TS user, this has bitten me many many times.
1 reply 0 retweets 1 like -
Replying to @wycats
we get plenty of reports on this in Flow too. We came up with an inline syntax but ppl would still make the mistake
@BrendanEich2 replies 0 retweets 2 likes -
Replying to @lbljeffmo @BrendanEich
what's the flow inline syntax? The problem is it's impossible to lint :(
1 reply 0 retweets 0 likes -
class X {} function foo({ x: X }} legitimately ambiguous :/ could try to guess.
1 reply 0 retweets 0 likes -
Replying to @wycats @BrendanEich
havent built only POC'd: function f({x: (y: X)}) {} Consistent w casting syntax and gen'izes annot grmr forall bindings
2 replies 0 retweets 0 likes -
Replying to @lbljeffmo @BrendanEich
argues against my { x as y } proposal, which might be nice
1 reply 0 retweets 0 likes -
let { x: y as X } or let { x as X } would be the same strategy in TS. it's not bad
1 reply 0 retweets 1 like -
Replying to @wycats
ya `:` syntax predates TS "as" - but want to be consistent w casting. Prob with "as": used in import for value binding
@BrendanEich2 replies 0 retweets 0 likes -
Replying to @lbljeffmo @BrendanEich
yeah which is why I want it in regular destructuring.
2 replies 0 retweets 1 like
foo({ x, y } as options) foo({ x: { y } as x })
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.