You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Request
The parameter types for IDL.decode should be updated to reflect the full range of types it can process at runtime. Ideally, it should accept all types it currently supports (Uint8Array<ArrayBufferLike> and ArrayBufferLike). At the very least, it should be made consistent with the actual runtime return type of IDL.encode (Uint8Array<ArrayBufferLike>).
Describe the bug
The parameter types of IDL.decode seem overly strict and inconsistent with IDL.encode. As discussed in dfinity/agent-js#950, the runtime return type of IDL.encode is actually Uint8Array not ArrayBuffer.
At runtime, this isn't an issue because IDL.decode can handle Uint8Array<ArrayBuffer>, Uint8Array<SharedArrayBuffer>, ArrayBuffer, and SharedArrayBuffer. Previously, type checking wasn't a problem because IDL.encode was typed as returning ArrayBuffer, which matched IDL.decode's expected input. This meant they aligned as ArrayBuffer at type check time and as Uint8Array<ArrayBufferLike> at runtime.
However, with the latest TypeScript transpilation target (ES2024), ArrayBuffer and SharedArrayBuffer (the two types that make up the ArrayBufferLike union) have diverged. This makes the discrepancies more pronounced, even though IDL.decode can work with any ArrayBuffer type or Uint8Array at runtime.
Request
The parameter types for
IDL.decode
should be updated to reflect the full range of types it can process at runtime. Ideally, it should accept all types it currently supports (Uint8Array<ArrayBufferLike>
andArrayBufferLike
). At the very least, it should be made consistent with the actual runtime return type ofIDL.encode
(Uint8Array<ArrayBufferLike>
).Describe the bug
The parameter types of
IDL.decode
seem overly strict and inconsistent withIDL.encode
. As discussed in dfinity/agent-js#950, the runtime return type ofIDL.encode
is actuallyUint8Array
notArrayBuffer
.At runtime, this isn't an issue because
IDL.decode
can handleUint8Array<ArrayBuffer>
,Uint8Array<SharedArrayBuffer>
,ArrayBuffer
, andSharedArrayBuffer
. Previously, type checking wasn't a problem becauseIDL.encode
was typed as returningArrayBuffer
, which matchedIDL.decode
's expected input. This meant they aligned asArrayBuffer
at type check time and asUint8Array<ArrayBufferLike>
at runtime.However, with the latest TypeScript transpilation target (ES2024),
ArrayBuffer
andSharedArrayBuffer
(the two types that make up theArrayBufferLike
union) have diverged. This makes the discrepancies more pronounced, even thoughIDL.decode
can work with anyArrayBuffer
type orUint8Array
at runtime.To Reproduce
Steps to reproduce the behavior:
The text was updated successfully, but these errors were encountered: