Normative: add set methods

[bakkot]

See proposal.

[jmdyck]

Rather than suggest changes here, I've filed a PR against the set-methods branch: #3308

[ljharb]

In isDisjointFrom, there's a "Set thisSize to the number of elements in O.[[SetData]]." line, but there's a bunch of other places that use SetDataSize. I see the difference - the AO skips empty values, the referenced line does not - but is that a problem? it seems like they should maybe all skip empty values?

[ljharb]

does this (and the below ToIntegerOrInfinity coercion) conflict with your "no coercion" initiative?

[bakkot]

Yup, but there wasn't much appetite to retroactively apply that to existing stage 3 proposals.

[michaelficarra]

If I was you, I would bring this one up. It's not like it will be hard or risky to do at this point.

[bakkot]

In isDisjointFrom, there's a "Set thisSize to the number of elements in O.[[SetData]]." line, but there's a bunch of other places that use SetDataSize. I see the difference - the AO skips empty values, the referenced line does not - but is that a problem? it seems like they should maybe all skip empty values?

Not a problem - the subsequent lines explicitly handle ~empty~ tombstones. And it needs to be the size of the full list, including ~empty~s, so it can iterate over it by index properly. (This happens in a few other places as well.)

[michaelficarra]

LGTM otherwise.

[gibson042]

Since "set" is a verb—and an especially common one in this specification at that, frequently paired with "get"—the new operation names strike me as a bit cumbersome (e.g., "SetDataHas" reads like "set the 'dataHas' of something" at first blush, rather then the "check if setData has a value" actually describing it). It would be nice to avoid such confusion by renaming them to avoid a leading "set" noun. Suggestions:

• SetDataHas → IsInSetData
• SetDataIndex → IndexInSetData
• SetDataSize → SizeOfSetData

I am aware that this deviates from the convention of starting operation names with the type of their first parameter, but a) that convention is not universal, cf. Operations on Objects, and b) the benefits of deviation seem to outweigh the drawbacks in this case.

[gibson042]

"Get" seems like an inappropriate prefix for an operation that constructs something new. Suggestion:

Suggested change

	<emu-clause id="sec-getsetrecord" type="abstract operation">
	<h1>
	GetSetRecord (
	_obj_: an ECMAScript language value,
	): either a normal completion containing a Set Record or a throw completion
	<emu-clause id="sec-createsetrecord" type="abstract operation">
	<h1>
	CreateSetRecord (
	_obj_: an ECMAScript language value,
	): either a normal completion containing a Set Record or a throw completion

(cf. CreateListIteratorRecord and Temporal Create*Record methods like CreateDurationRecord for this pattern, and also Make{DataView,TypedArray}WithBufferWitnessRecord and other "Make" operations or even "New" operations like NewObjectEnvironment for alternatives, although I think "Make" is more often used to create language values and "New" for environment records. I would also like to address existing uses of the "Get" name like GetIteratorFromMethod, but at least this PR can avoid the bad precedent)

[bakkot]

Addressed @michaelficarra comments.

@gibson042 Re: naming, I lightly agree, but since this has already been implemented in various engines with explicit references to these names I'm inclined to keep them at this point. I don't think the benefits of marginally better names is worth having different names in engines vs the spec.