Skip to content

Add missing Uint8Array.setFromHex extern.#4306

Closed
KimlikDAO-bot wants to merge 2 commits intogoogle:masterfrom
KimlikDAO-bot:setfromhex
Closed

Add missing Uint8Array.setFromHex extern.#4306
KimlikDAO-bot wants to merge 2 commits intogoogle:masterfrom
KimlikDAO-bot:setfromhex

Conversation

@KimlikDAO-bot
Copy link
Contributor

Supplements 64b6c77

Copy link
Contributor

@niloc132 niloc132 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for catching this!

@lauraharker lauraharker self-assigned this Mar 17, 2026
@KimlikDAO-bot
Copy link
Contributor Author

KimlikDAO-bot commented Mar 17, 2026

Apologies for the non-compiling PR. Here's what happened:

Each declaration type in gcc has one identity dimension [@constructor, @interface, @record] and one shape dimension [@struct, @unrestricted, @dict].

For better optimization, @interface's are preferred over @record's, but they can be more unergonomic when constructing the object. For return value like this, this issue doesn't occur and @interface's basically have no downside; you can still destructure out of interfaces without a cast:

const { written, read } = myUint8Array.setFromHex("FF");

By default, @interface's declared in this older constructor / prototype pattern have the @unrestricted shape. That's why we explicitly mark it as a @struct, which means you cannot do res["written"] but have to access the properties like res.written.

So to summarize, the ideal identity and shape for this return type appears to be @interface @struct, which is what this CL does.

copybara-service bot pushed a commit that referenced this pull request Mar 17, 2026
@lauraharker
Copy link
Contributor

Thanks for the fix!

Merged in a9579d2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants