Skip to content

Conversation

@tlively
Copy link
Member

@tlively tlively commented Jan 16, 2026

Describe overloading the existing string builtins to be importable with shared versions of the existing signatures.

Describe overloading the existing string builtins to be importable with shared versions of the existing signatures.
@tlively tlively requested a review from conrad-watt January 16, 2026 01:02
@tlively
Copy link
Member Author

tlively commented Jan 16, 2026

cc @manoskouk, @jakobkummerow, @Liedtke

Copy link

@Liedtke Liedtke left a comment

Choose a reason for hiding this comment

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

Sounds good!

Copy link
Contributor

@jakobkummerow jakobkummerow left a comment

Choose a reason for hiding this comment

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

LGTM with a nit.

@jakobkummerow
Copy link
Contributor

What about magic string constants in imported globals? Do we need importedSharedStringConstants: "some_namespace"? Or should the existing mechanism be generalized similarly to the functions, i.e. (global $helloworld (import "'" "hello, world!") (shared externref)) will be populated with a shared string because of its type?

tlively and others added 2 commits January 16, 2026 10:59
Co-authored-by: jakobkummerow <jkummerow@chromium.org>
@tlively
Copy link
Member Author

tlively commented Jan 16, 2026

@jakobkummerow, good point. I added a paragraph now about imported strings. There's no need for a separate namespace for shared strings.

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.

4 participants