Allow `await.cancelToken = null`

[bergus]

I like that better than undefined; I think we should allow both values. With the current semantics, a TypeError is thrown.

[domenic]

We should definitely not allow both values; we need to pick one and stick to it. undefined seems more appropriate since that's the default...

[bergus]

What's wrong with both values? They seem to be used almost interchangeably in the JS community when the purpose is to "not be an object". There are arguments for both, null is shorter, cannot be shadowed, and means "no object" more literally; while undefined is the default "no value" that gets returned from functions, unassigned variables, parameters or properties. It's considered only a matter of personal style which one to use. Surely there's precedent for a distinction between them with default initialisers, but I don't think we need to make one here. Just supporting both would make the feature more accessible I think, throwing off no one.

[domenic]

It's definitely not a matter of personal style. undefined is what is used to trigger default behavior in JavaScript. Supporting both makes await.cancelToken a one-bit communication channel within the function with no purpose. (I don't think it's a security problem, but it's just strange to entangle the one-bit-communication channel use case with the canceling awaits use case).

[bergus]

I meant that it's purely a matter of choice where the difference does not matter (which is quite often). In those circumstances, some programmers prefer to write undefined and others prefer to write null. Since "null is used by programmers to indicate “no value”" [1], it might throw some people off when they try to assign that to await.cancelToken.

I can't see how await.cancelToken might be considered a communication channel. It's limited to the scope of a single function, the meta property behaving quite like a normal variable (at least that's what people will expect from assignment). If you wanted to communicate through it, you can by sharing a token object anyway. I understand your concerns about unnecessarily adding more complexity to the state space, but I believe it would be more user-friendly.

[annevk]

Hmm, we stopped treating null and undefined as equivalent throughout the platform. I agree with @domenic that not adding null would be better. If null sometimes means the same thing, but not always, that just ends up being confusing. And we can't make them always behave the same.

[bergus]

Hmm, we stopped treating null and undefined as equivalent throughout the platform.

Yes, they are not equivalent, but it's also confusing to distinguish them unless there is an already-documented difference. Is there any guide which one to choose when you are not sure? The standard itself says "undefined is the primitive value used when a variable has not been assigned a value" and "null is the primitive value that represents the intentional absence of any object value", which would suggest that the initial value of await.cancelToken is undefined but when you assign to it you'd use null.

I agree that not adding null would be better

I'm fine with that decision, I just wanted to get some discussion.

[domenic]

Yes, they are not equivalent, but it's also confusing to distinguish them unless there is an already-documented difference.

There is an already-documented difference, as I said earlier on this thread. undefined is what triggers default values and behaviors in JavaScript; null does not.

[benjamingr]

I also think undefined is better - and it looks like the four of us all agree on it. I think this can be closed now.