swiftwasm / swiftwasm/JavaScriptKit

`JSNumber` type to support `long long` type in Web API IDL

未關閉
#194 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

enhancement
主要語言
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

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 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

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。