03:24 | <ljharb> | of course they are; import type vs import , "what gets stripped" vs "what doesn't", etc |
03:25 | <ljharb> | i would be surprised if any user actually didn't understand that typescript wasn't what runs in the actual application |
05:47 | <sffc> | About Decimal and primitives, littledan's logic makes a lot of sense to me. If we were to have decimals as a primitive, they would need to be normalized (no quantum). However, the champions have presented rationale for why decimals should retain their quantum. Therefore, Decimals should be objects, not primitives. This logic flows completely independently from any argument about whether or not engines may eventually change their position on decimals being a new primitive. |
07:55 | <Luca Casonato> | i would be surprised if any user actually didn't understand that typescript wasn't what runs in the actual application |
08:14 | <Rob Palmer> | In the old days, folk learned JS before they learned TS, so had a strong mental model of the difference. Nowadays many people learn TS first (or at least, it's not sequenced). And we have runtimes with built-in support, further hiding the difference. |
17:42 | <ljharb> | are most of those newcomers using those alternative runtimes tho? |
17:53 | <Anthony Bullard> | Definitely not. Most still use the browser - though through transpilers - or node(same). |
17:59 | <ljharb> | that matches my intuition - anyone who's using "not browsers or unflagged node" is not a newcomer and knows the difference. |
18:25 | <Justin Ridgewell> | of course they are; deferred /immediate seems very similar to readonly in readonly number[] which tells the user they can’t don foo[0] = 1 . derred () => void means they can’t call that function within their function body, only pass it off to another deferring function or store it for later. |
19:40 | <ljharb> | : readonly number[] tho. it's part of the type. |
20:47 | <Justin Ridgewell> | Yes, and : deferred () => void is part of the type, too. |
20:48 | <Justin Ridgewell> | The type system should error if you call a defferred callback sync, the same way it will if you mutate a readonly array. |
22:56 | <shu> | is the only way to observe number of ticks via user code if i have some spec doing the following:
where |
23:06 | <bakkot> | shu: do you meant to have let p3 = PerformPromiseThen(p2, () => p1, () => {}); return p3 ? Or are you really intending to return the original p2 ? |
23:08 | <shu> | i am intending to return original p2 , that's a PerformPromiseThen as in our AO, not p2.then |
23:08 | <shu> | like p2 does nothing except inherit p1's eventual state |
23:09 | <shu> | wait i think that pseudocode is just borked |
23:10 | <shu> | it's like PerformPromiseThen(p1, () => Resolve(p2)) |
23:16 | <bakkot> | in this example p1 never resolves so it is perforce not observable |
23:16 | <bakkot> | perhaps you intend p1 to start out resolved? |
23:18 | <shu> | yes, i think starting out resolved is equivalent to what's actually happening |
23:20 | <bakkot> | in which case, the difference is observable iff someone is keeping track of ticks while this all is going on, I believe? which they could be |
23:20 | <bakkot> |
|
23:24 | <shu> | ah, of course, thanks for the example |
23:24 | <shu> | cursed global queue |
23:56 | <ljharb> | Yes, and |