Return value of mutation methods on collections

Hi,

Currently, `(Weak)Map.prototype.set` and `(Weak)Set.prototype.add` are specified to return the collection on which the method is applied.

It seems logical to extend that scheme to other mutation methods, namely `.delete()` and `.clear()`.

—Claude

On Tue, Sep 23, 2014 at 12:57 PM, Claude Pache <claude.pache at gmail.com> wrote:
> Hi,
>
> Currently, `(Weak)Map.prototype.set` and `(Weak)Set.prototype.add` are specified to return the collection on which the method is applied.
>
> It seems logical to extend that scheme to other mutation methods, namely `.delete()` and `.clear()`.

.delete() returns a bool for whether it deleted something; it's not a
void return type which can be usefully set to the collection instead.

~TJ

Le 23 sept. 2014 à 22:33, Tab Atkins Jr. <jackalmage at gmail.com> a écrit :

> On Tue, Sep 23, 2014 at 12:57 PM, Claude Pache <claude.pache at gmail.com> wrote:
>> Hi,
>> 
>> Currently, `(Weak)Map.prototype.set` and `(Weak)Set.prototype.add` are specified to return the collection on which the method is applied.
>> 
>> It seems logical to extend that scheme to other mutation methods, namely `.delete()` and `.clear()`.
> 
> .delete() returns a bool for whether it deleted something; it's not a
> void return type which can be usefully set to the collection instead.
> 
> ~TJ

Is the current `.delete()` return value more useful than the proposed one?

Anyway, I thought more about consistency than about usefulness; because for each method, there are several potentially useful return values. (For example, the `.set()` and `.add()` methods could arguably return the value just set/added, just like `foo.bar = value` is `value`, or `foo.appendChild(node)` is `node`, which I find both positively useful in practice.)

—Claude