Discuss
  • Return value of spec setters?

Return value of spec setters?

# Erik Arvidsson (11 years ago)

ecmascript#2511

We now have our first setter in the spec. However, it is speced to return the value itself. This is pretty inconsistent with WebIDL and the common practice to not include a return value in setters in object literals.

Can we get the spec changed to return undefined?

# David Bruant (11 years ago)

In practice, the returned value of setting is the value on the rhs of the =.

 var o = {set b(v){return 12;}} // this return statement is useless

 console.log(o.a = 13); // 13
 console.log(o.b = 14); // 14

It might be useful to return a different value on setting. I think Haxe does it. Note that it would require to rework the set trap of proxies a bit (currently, it returns a boolean indicating success or failure).

Can we get the spec changed to return undefined?

That would be the most coherent option with the language as it is today.

# Allen Wirfs-Brock (11 years ago)

On Feb 18, 2014, at 9:55 AM, Erik Arvidsson wrote:

Can we get the spec changed to return undefined?

undefined seems fine, as the result of the set function is never returned to userland when it is invoked as a setter.

# Brendan Eich (11 years ago)

David Bruant wrote:

It might be useful to return a different value on setting.

Just Say No.

# Boris Zbarsky (11 years ago)

On 2/18/14 1:07 PM, David Bruant wrote:

In practice, the returned value of setting is the value on the rhs of the =.

That's the value of an assignment expression, yes.

 var o = {set b(v){return 12;}} // this return statement is useless

Unless you explicitly getOwnPropertyDescriptor("o", b).set.call(o, 13), yes.

# Andrea Giammarchi (11 years ago)

just my 0.02, setter, considered inline, are more like:

return doSomethingWith(name, value), value;

than

var result = doSomethingWith(name, value);
return result === undefined ? value : result;

also because returning undefined, as setting undefined, would be a valid and totally ambiguous operation.

In first case at least, it's never ambiguous, you know that value you are passing to set is the one you'll have back, no matter what, unless Error occurs.

A trick to "return" something else during a set can be throwing {another:'value'} indeed and catch it later on ... but it's a very weird pattern I would personally not recommend.