Rename memory.drop and table.drop?

[julian-seward1]

The names memory.drop and table.drop are confusing in the sense that they don't have any effect on a memory or a table. Instead they modify (the validity of) data and element segments respectively. This is confusing for newcomers to the proposal, and it's also inconsistent with the other 5 proposed instructions, which do act on the object in their names.

I think it would be better to rename them thusly:

memory.drop --> dataseg.drop
table.drop --> elemseg.drop

Then consistency is restored, and it's clear what they actually act on.

[lars-t-hansen]

I agree these instructions are misnamed and that we should consider renaming them. @binji, something for the next CG meeting?

[binji]

OK, I've added this to the November 13 meeting.

[alexcrichton]

Another possible way to rename these could be {table,memory}.drop_segment

[binji]

We discussed this briefly in the Nov 13 CG meeting, but didn't make much progress. It seemed that everyone agreed that we should change the names, but we didn't land on what they should be.

It seems that the two described here were most popular, either:

{data,elem}.drop

or

{table,memory}.drop_segment

Keeping table and memory prefix is nice because it aligns well with {table,memory}.init. But {data,elem}.drop more directly expresses what the instruction does.

[rossberg]

I vote for {data,elem}.drop. An intermediate option would be {table,memory}.drop_{elem,data}, given that "segment" is not currently used anywhere else.

[binji]

{table,memory}.drop

[binji]

{data,elem}.drop

[binji]

{table,memory}.drop_{elem,data}

[binji]

{table,memory}.drop_segment

[binji]

Vote for your favorite above (using GH reactions)!

[binji]

Looks like {data,elem}.drop just barely wins. I'll update the docs to reflect this.