-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Treating null
as undefined as well
#4
Comments
Thanks for summarizing! Everyone, feel free to vote on the suggestion with thumbs up/down emoji. On the theoretical side, it might be nice to distinguish any existing property of a JSON container from a missing one, e.g. let systemConfig = require('/etc/foo.json');
let localConfig = require('./foo.cfg.json');
function worldsBestJsonValue() {
v = (systemConfig.bestJsonValue ?| localConfig.bestJsonValue);
if (v === undefined) { throw new Error('no idea'); }
return v;
} |
Just found the Null Coalescing proposal. Link is now in the readme, too. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: