You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following is a brief summary of a discussion that was had on IRC.
I feel that when considering whether something is 'defined', it should treat null in the same way as undefined; in the current proposal, it treats null as a defined value. Given the following points:
It's undesirable to introduce two operators for the different cases ("only ignore undefined" vs. "ignore undefined and null"), as this would introduce confusion and possibly make it easy for readers to misinterpret what a given piece of code is doing.
An "escape hatch" will be needed; either of the two cases needs to be representable, but only one of the cases can have an operator assigned to it. Therefore, the other case needs to have a different, reasonably ergonomic, non-operator representation.
Operators are expensive to introduce (there are only a few possibilities in terms of characters used), and cheap to use (not a lot of work to read and write, and easily recognizable); therefore, the operator should be used for the common case. This maximizes the benefit that the developer gets from the use of a relatively scarce operator 'slot'.
In the JavaScript ecosystem, the bulk of libraries treat null and undefined interchangeably; libraries often don't even document which they will return, some of them return either of them inconsistently, and so on. In practice, this means that as a consumer of third-party code, "handling null and undefined as equivalent" is a common case.
It's extremely rare to run into cases where there is a meaningful technical distinction between null and undefined. In almost all cases where there is a distinction, either only one of them is ever used (but it could be either one), or the distinction is purely philosophical (eg. explicitly vs unintentionally empty value) and has no effect on real-world code that's written around it.
... it would seem logical to change the meaning of the ?| to include both nullandundefined.
To rehash which cases this covers:
null and undefined used interchangeably (common): Covered.
Only null or only undefined used, but not both (common): Covered.
Philosophical difference between null and undefined, but no practical consequences (uncommon): Covered.
Meaningful technical difference between null and undefined, where both options need different treatment in consuming code (uncommon): Not covered.
This leaves the question of the 'escape hatch' - if a developer does need to express an explicit check for undefined that doesn't include null, how can they represent this? The obvious solution to this seems to be to use the proposed 'decider' mechanism (for which I have some separate suggestions for improvement).
The text was updated successfully, but these errors were encountered:
The following is a brief summary of a discussion that was had on IRC.
I feel that when considering whether something is 'defined', it should treat
null
in the same way asundefined
; in the current proposal, it treatsnull
as a defined value. Given the following points:null
andundefined
interchangeably; libraries often don't even document which they will return, some of them return either of them inconsistently, and so on. In practice, this means that as a consumer of third-party code, "handlingnull
andundefined
as equivalent" is a common case.null
andundefined
. In almost all cases where there is a distinction, either only one of them is ever used (but it could be either one), or the distinction is purely philosophical (eg. explicitly vs unintentionally empty value) and has no effect on real-world code that's written around it.... it would seem logical to change the meaning of the
?|
to include bothnull
andundefined
.To rehash which cases this covers:
null
andundefined
used interchangeably (common): Covered.null
or onlyundefined
used, but not both (common): Covered.null
andundefined
, but no practical consequences (uncommon): Covered.null
andundefined
, where both options need different treatment in consuming code (uncommon): Not covered.This leaves the question of the 'escape hatch' - if a developer does need to express an explicit check for
undefined
that doesn't includenull
, how can they represent this? The obvious solution to this seems to be to use the proposed 'decider' mechanism (for which I have some separate suggestions for improvement).The text was updated successfully, but these errors were encountered: