swiftwasm / swiftwasm/JavaScriptKit
`JSNumber` type to support `long long` type in Web API IDL
還沒有人認領這個 Issue。
- 主要語言
- Swift
- 星號
- 986
- 分支
- 76
- 平均合併
- 21 小時 11 分鐘
- 30 天內合併 PR
- 4
描述
Rust folks have a similar issue, where long long shouldn't be mapped to Int64, which is bridged to BigInt on JS side. https://github.com/rustwasm/wasm-bindgen/issues/800
Checked a few other places where long long is used, like AudioData, Blob, and File and all of them return a JS number in corresponding properties, not BigInt. I'm 95% sure none of these support BigInt, remaining 5% certainty could be added by writing actual tests. I personally vote for either keeping these Int32 as proposed, or creating a new union type. Just riffing:
enum JSNumber: ExpressibleByIntegerLiteral, ExpressibleByFloatLiteral {
case integer(Int32)
case float(Double)
// ...
}
Should we add such type to JSKit then?
cc @kateinoigakukun
Originally posted by @MaxDesiatov in https://github.com/swiftwasm/WebAPIKit/issues/42#issuecomment-1125355976
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
研究方向
先檢視 JSKit 對 Web API IDL long long 值的處理方式,並將 issue 中提到的 AudioData、Blob 和 File 屬性與 wasm-bindgen issue 800 進行比較。要視為完成,需要決定 JavaScript 數字的表示方式,並透過測試確認這些屬性是否支援 BigInt;沒有指定實作檔案或測試。
由索引模型根據 Issue 內容生成。
評估
- 技術堆疊
- javascript, swift, wasm
- 領域
- api, web-dev
- Issue 類型
- 功能
- 難度
- 5/5
- 預估耗時
- 一週以上
- 活躍度
- 停滯
- 描述清晰度
- 需要釐清
- 新手友好度
- 25/100