Normative: Return this on %TypedArray%.prototype.set

[leobalter]

Even if this change is super small, it's good to have more feedback, mostly from implementors.

Historically, %TypedArray%#set returns undefined in the Khronos spec, I believe that's the reason we have it this way.

I've talked to some developers with background experience on TypedArrays and WebGL and asked if this change would be useful. They confirmed it's a handy change. Plus, it allows chainable calls and makes it a bit more consistent with the other JS methods, like TypedArrays or even Map#set.

The main and only concern is performance. I informally asked a few implementors and it looks the impact wouldn't be a problem, if any. I would like to have more feedback on this part.

[domenic]

I am against this. I prefer preserving command query separation for APIs, even if we have notably failed to do so in a few other cases.

This requires a proposal that advances through the process, of course.

[claudepache]

a bit more consistent with [...] even Map#set.

It’s ironic to mention possible consistency with Map#set, because the Map interface is internally very inconsistent, with its three mutation methods (set, delete and clear) returning three different types of result.

[leobalter]

these mutation methods has different goals. My focus is on methods to add new items. I used Map#set as an example as I remember I wrote a specific test for the return value on test262, I missed this behavior on the tests for %TypedArray%#set.

TypedArrays are not Maps and are not used for the same level of work. In anyway, if you consider they are native APIs, I would expect something similar.

The following data shouldn't add much value to this discussion, as TypedArrays are from their kind, but was my first motivation:

• Map#set
• WeakMap#set
• Set#add
• WeakSet#add

Even Array#push does not return undefined, but that's not a good example on the matters of returned values.

---

The DataView#set* methods return undefined too, but I believe this previous discussion is necessary before going forward on them.

[leobalter]

@domenic: I prefer preserving command query separation for APIs, even if we have notably failed to do so in a few other cases.

I understand the preference but I like JS being a multi-paradigm language. This change offers an interesting alternative without breaking anything.

This requires a proposal that advances through the process, of course.

I guessed it bad. I agree this need consensus, but thought it could be solved on this PR. If I need to make a proposal for this, this discussion may help to at least collect some data, even to tell me it's worth the time.

[bterlson]

Agree this is probably a proposal thing. We haven't used the PR process for minor feature requests before, at least, but if people would like to entertain something like this as a PR we could discuss whether it's appropriate in Munich.

Re: the content of this proposal, seems ok to me so long as it doesn't break anything (and it seems very unlikely it would).

[allenwb]

I'm pretty sure that this pattern (and perhaps this specific API) has been discussed at TC39 meetings before and that the consensus was that for consistency we should continue to follow the legacy pattern which as @domenic pointed out above is essentially the command-query separation pattern.

It would sure be nice if we had a more accessible record of such decisions. Anybody want to digest all the old meeting notes?

[leobalter]

It would sure be nice if we had a more accessible record of such decisions.

It would be great.

Now I'm currently testing the Dataview set methods and it seems there's more to change if I want to move it forward. Before any change proposal - or none, perhaps - I'll read and search the old meeting notes.