Ingvar Stepanyan

@kerryjiang :+1: Just please note that `MessageWebSocket`-based part should be marked not just for WinRT (Windows 8.1) but also for Windows Phone 8.1 so it could be used in Universal...

@kerryjiang Yes.

> In Rust we could just throw an error from the derive macro Yeah we can do basically the same thing in C#, actually even easier than in Rust because...

> especially with having to copy-paste same two fields (from docs?) in each such table. Although I guess we could also combine them into a single struct, so users would...

> Combining them into a single struct is challenging because it prevents the `scheduled_id` from being auto-inc. Ugh, right...

Just to list one more alternative I thought of, in C# we could just use inheritance, with those 2 fields living in some base abstract class, but that doesn't help...

> We also can't really handle names for generic types correctly in codegen because sats has no notion of generics, except for array, map, and the slightly kludgey implementation of...

> And it seems to break rust-analyzer, which gives "no such field" errors when you access these fields. Btw, is your Rust Analyzer configured to run proc-macro? I don't remember...

I narrowed down the cause to this part: https://github.com/rustwasm/wasm-bindgen/blob/7302d644191bc36abe41bd0086732685061ce90e/crates/cli-support/src/wit/mod.rs#L170-L172 It assumes that the table should be preserved only if there are closure imports, but doesn't account for stack closures which...

I don't think this in particular is a bug tbh. It was an intended behaviour to match native platforms more closely when executing on Node.js, otherwise any background thread would...