DEV Community

Discussion on: The Semantics of Falsy Values

 
blindfish3 profile image
Ben Calder

Yes. Did you try running the code? It demonstrates precisely what I described. It's not uncommon to use the return value from one function as the calling argument in another. In this case returning null negates the usefulness of the default argument; since you still need an explicit check for null in the function body if you want to return the default.

I'll update the function names to make the example clearer; and add another possibility ;)

Thread Thread
 
somedood profile image
Basti Ortiz • Edited

Apologies. I misread the code.

Anyway, I would argue that that's correct and reasonable behavior because null was explicitly passed in as an argument, whereas passing undefined as an argument would implicitly call upon the default value to be used as the definition in stead.

This goes back to what I said in the article where null communicates the express intent to pass absolutely nothing, whereas undefined communicates the absence of a definition. null does not, in fact, negate the usefulness of the default value if used correctly in this context.

So, really, the only issue in this code snippet is its noncompliance with the semantics of the language, which is what brings about the "issue" you presented in the first place.

Thread Thread
 
blindfish3 profile image
Ben Calder • Edited

I agree that passing null to a function does show an explicit intent that is different to not passing an argument... But I think the original question - and certainly my example code - relate to whether a function should return null or undefined to represent a falsy value; given that returning null then makes it impossible to leverage default arguments. You seem to be suggesting that null is always more appropriate.

I'd tend to use null if the failure of a function to return something is going to block further execution; so yes - in the context of document.getElementById it makes sense since you presumably want to do something with that element once you retrieve it and there isn't going to be an obvious default. But in other contexts the returned value may not be essential for things to keep running; in which case I'd argue that undefined is totally appropriate. Of course, right now, I can't think of a good example :shrug:

Thread Thread
 
somedood profile image
Basti Ortiz • Edited

Okay, your argument is much clearer to me now. Thanks for the clarification. I now see the issue of returning null in this case.

For me, I'd still like to believe that even though the default parameter has been rendered useless due to the return value of null (as you presented in the snippet), the omission of the default value is still is semantically correct given that an intentional null was passed as an argument as the definition of the parameter.

However, I do agree about how it has basically made the default value useless, especially if one expects JavaScript to "fall back" to a default value if the argument passed in is a falsy value.

To appease both of our equally valid arguments, I'd say that we should refrain from using defaulted parameters as mere "fallbacks" to falsy values. For me at least, semantically speaking, the default parameter has always been there to allow a function to be executed despite having some of its parameters not being defined upon invocation. By restricting ourselves to only using default parameters when an invocation lacks all arguments, we can avoid the issue you presented since null would never be treated as a falsy value that needs a "fallback" in the first place (since null is the definition itself).

But I can see how my compromise may seem unsatisfying, to be honest. To that I say, "to each its own". Each of us has our own coding styles and philosophies. For me, I would never treat null as a falsy value that needs a default because I interpret null as a sufficient definition in itself.

TL;DR: null is not supposed to have a "fallback" in the first place.

Thread Thread
 
blindfish3 profile image
Ben Calder

Agreed: I think I already said that it makes sense for null not to have a fallback ;)

Anyway, I had time to think of some examples to illustrate when it may make more sense to return undefined from a function:

  • a helper function to select an optional property that may be deeply nested on an object. If I try and directly access an object property that doesn't exist I get undefined. It makes more sense to me to also return undefined from my helper function than to explicitly return null
  • a function that processes some form of optional input. If input is not provided it is undefined. In this case I'd be inclined to also return undefined

In both these cases it may be desirable to allow another function that accepts these return values to provide a default fallback.

To be clear: these comments aren't intended as criticism. I found your article interesting; especially since misunderstanding of falsy values and coercion often lead to unintended errors - e.g. the common use of the shortcut if(someValue) to determine that a value is defined falls flat when dealing with numerical input that may be 0...
But I also thought @tom 's question was justified. I think the confusion comes from this line in the article:

It is for this reason why null is more correct and desirable than undefined when returning nothing.

Was that intended to be meant specifically in the context of an object search; or as a general directive for returning nothing from any function? I'd disagree with the latter assertion for the reasons outlined above: I'd argue that context is more important in determining what is a semantically correct falsy value to return than having a rule that is set in stone: "never say never" ;)

Thread Thread
 
somedood profile image
Basti Ortiz • Edited

Oh, no! Don't worry about it. I take no offense because I know that this is an educated discussion. 😉

As for the examples you provided, I definitely agree with them. I think it semantically makes sense to return undefined in your examples since the values of the fields haven't been defined in the first place. In other words, what I'm trying to say that your usage of undefined is truly valid and justifiable in those specific contexts.

In regard to the quote you cited, I see now how my wording can be misinterpreted and may have implied that undefined is "always" wrong. That is my mistake. When I wrote the sentence you quoted, what I meant by it is that null should always be returned if the intent is to literally pass absolutely nothing.