Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename Index Type to something else, perhaps Offset Type #67

Closed
Tracked by #43
sbc100 opened this issue Jun 24, 2024 · 10 comments · Fixed by #90
Closed
Tracked by #43

Rename Index Type to something else, perhaps Offset Type #67

sbc100 opened this issue Jun 24, 2024 · 10 comments · Fixed by #90

Comments

@sbc100
Copy link
Member

sbc100 commented Jun 24, 2024

No description provided.

@bvisness
Copy link
Collaborator

What's wrong with "index type"? I haven't been following #50 very closely, but I struggle to think of a better term generally. If it were only memories, you could call it an "address type", but since tables are in the mix I think "index" is the better general term.

@sbc100
Copy link
Member Author

sbc100 commented Jun 25, 2024

Context: #50 (comment)

@bvisness
Copy link
Collaborator

If I'm understanding correctly, the spec today currently doesn't choose an official name like "index" for the parameter to table.get, but I think "index" is clearly implied - the execution instructions use i for the parameter name, and the structure section uses "index" to refer to one of the parameters of table.copy.

Anyway, unless there's something I'm missing, I think "index type" is a perfectly good term that I'd vote to keep.

@sbc100
Copy link
Member Author

sbc100 commented Jun 25, 2024

I'm basically neutral on this. I've gotten used to calling it index type, so there is some inertia there I suppose.

@rossberg
Copy link
Member

@bvisnuss, i is universally used for integers.

I'd prefer avoiding overloading terminology in potentially confusing ways. We already use the term "index" for all the index spaces, and in particular, "memory index" and "table index" already have a different meaning. Moreover, while "index" is natural for tables, it is less so for memories. Hence I suggested "offset" as a more neutral and unclobbered name, but perhaps there are better suggestions.

@tlively
Copy link
Member

tlively commented Jun 25, 2024

I agree that "index" is the most natural term in isolation, but I do agree that avoiding overloading it is a good idea. I would prefer "address" over "offset," even for tables, and it would be an even less overloaded term. It would be weird to explain the offsets in memargs as being "offsets from an address/index that has an offset type."

@rossberg
Copy link
Member

Address type (addrtype) sounds good to me.

@bvisness
Copy link
Collaborator

bvisness commented Aug 1, 2024

I've been making a variety of spec updates in #71, and would be happy to change "index type" to "address type" as part of that PR if people agree. Any objections?

@sbc100
Copy link
Member Author

sbc100 commented Aug 1, 2024

@bvisness just FYI I've been doing all my recent spec work on the wasm-3.0 branch of this fork, not the main branch. This is so that all our work here can be merged into the wasm-3.0 branch in the upstream spec repo.

@bvisness
Copy link
Collaborator

bvisness commented Aug 14, 2024

I'm working on a PR for this issue. This is an almost invisible change to users except for one thing: the index parameter on table and memory descriptors, used in the Table and Memory constructors.

Presumably this parameter should be renamed. Should it be renamed to addressType or address?

hubot pushed a commit to v8/v8 that referenced this issue Oct 21, 2024
This was discussed in WebAssembly/memory64#67
and changed in WebAssembly/memory64#90.

This is a pure mechanical renaming of "IndexType" -> "AddressType" and
"index_type" -> "address_type".

[email protected]

Bug: 41480462
Change-Id: Ifb6843ca47d9a48d7aac3d7f64d0f7c7ce4ecec5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5941627
Commit-Queue: Clemens Backes <[email protected]>
Reviewed-by: Eva Herencsárová <[email protected]>
Cr-Commit-Position: refs/heads/main@{#96704}
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 a pull request may close this issue.

4 participants