`bytes` as alias for `list<u8>`
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- javascript, wasm
调研方向
Start by reading the new JS explainer in #686 and the issue’s discussion of list at the ABI level. Determine whether bytes should remain an alias there, then establish the accepted JavaScript mappings for list and bytes, including parameter behavior and Uint8Array handling.
由索引模型根据 Issue 内容生成。
描述
While reading through the new JS explainer in #686, I found myself going back and forth on whether to use typed arrays for list<num>. For list<u8> it seems fairly natural to map that to Uint8Array, but less so for other number types. Like, it's probably quite a footgun to return Int32Array for list<s32>, since most JS devs don't use typed arrays very often, and typed arrays look juuuuuust enough like normal arrays to do some really surprising things:
> new Int32Array([1, 2, 3]).map(n => `item ${n}`)
Int32Array [0, 0, 0]
Surely no one would complain about this.
But that got me thinking - the main difference seems to be that sometimes you want a list of numbers, using whatever list type is idiomatic, but sometimes you just want a blob of bytes. Sure, you can have Int32Array and Float64Array and so on, but at least 95% of the time in JS you just want Array. And after further reflection, I think this is true of other languages too! In C++, do you really want a std::vector<uint8_t>, or would you maybe prefer std::string or some other kind of slice type? In Java, do you want List<Byte> or byte[]? In Python, do you want list or bytes? In Rust, do you want Vec<u8> or &[u8]?
(This is not true for some languages, e.g. Go would always do []byte, but that's fine, the distinction doesn't have to be meaningful in every language.)
So, purely as a hint to bindings generators, I think there is probably some value in having a bytes type that is in every way just an alias for list<u8>. Certainly there is no need for it to be different at the ABI level.
If accepted, I would suggest the following for the JS mapping:
list<T>is returned as a JS array, and as a param only accepts a JS array (...or iterable? idk)bytesis returned as aUint8Array, and a param accepts anything the TypedArray constructor would (which encompasses all typed arrays, ArrayBuffers, and JS iterables)
- 主要语言
- WebAssembly
- 星标
- 1.4k
- 派生
- 132
- 平均合并
- 2 天 20 小时
- 30 天内合并 PR
- 13
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
WebAssembly/component-model 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
WebAssembly/component-model#609 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
WebAssembly/component-model#727 · 3 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
WebAssembly/component-model#724 · 10 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 25/100
WebAssembly/component-model#695 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 45/100
WebAssembly/component-model#694 · 1 条评论 ·
维护者通常 1 天内回复
查看 WebAssembly/component-model 的全部 Issue
相似的 Issue
-
priority: low 🌱 type: enhancement 💅🏼
难度 2/5 半天 新手友好度 84/100
nebari-dev/llm-serving-pack#199 ·
维护者通常 3 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
linebender/parley#849 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
rohitg00/agentmemory#1428 ·
维护者通常 1 天内回复