Default operator strawman - ||| rather than ??

[Herby Vojčík]

Thaddee Tyl wrote:
> On Tue, Jun 12, 2012 at 10:17 PM, David Herman<dherman at mozilla.com>  wrote:
>> On Jun 12, 2012, at 6:33 PM, Thaddee Tyl wrote:
>>
>>> My point still stands. Being "undefined"-specific is arbitrary.
>>> CoffeeScript could have been "undefined"-specific; they were
>>> "undefined" + "null"-specific, which I believe makes more sense.
>> Can you make the full argument? I'm genuinely undecided on this question, and having trouble deciding on the criteria.
>
> "undefined" and "null" share a lot of behavior that other falsy values
> don't have.
> The most critical one is to throw a TypeError on some occasions,
> including when invoking the abstract ToObject operation.
> Besides, it often has a similar meaning: I have seen in a lot of code
> a de-facto standard wherein null is used to indicate a value that is
> voluntarily undefined. You can see this pattern all over node.js code,
> for instance.

Yes. I find this pattern a little smelly, though. It is an optimization 
for V8 - delete foo.x changes foo to plain slow hashtable, but foo.x = 
null does not.

> This lets the user know when a parameter was meant to be set to
> nothing, and when we should use a default parameter instead.
> Harmony's default parameters will make this easier, while letting a
> null value through -- which will make this pattern even more common.

But here, it is semantic difference - null means "nothing, chosen by 
will". Undefined means "nothing, as a consequence of not being defined".

> On the other hand, we often want to react in a certain way if the
> parameter is not set, either because it was not supplied or because it
> was set to null.

I find the "or" here a bit misleading - to react if parameter is not set 
is to react to undefined.

> Besides, the null value can be obtained from the standard library,
> when calling certain methods.
> Object.getPrototypeOf(...), string.match(...), even calling the toJSON
> method of a Date can return null.

Object.getPrototypeOf(...) return null for a reason. It is not 
"semantically undefined", it is very well defined, being "the prototype 
chain stops here, no more parents".

> Having a way to deal with those return values by providing a default
> value would be nice.

As I see it, it is much clearer (in the good code design and style 
sense) to only react to undefined.

But under "paving the cowpaths" philosophy, I am afraid null+undefined 
is what will be considered as the implementation.

Herby

P.S.: It also saves more code if ??/?= will react to undefined. Properly 
testing undefined needs

typeof foo === "undefined"

while properly testing for undefined+null only needs

foo == null

.

P.P.S.: It would be helpful if delete could be made fast in V8 and 
foo=null discouraged... though I can't imagine how.