Actionable: Logical operators should return the truthy/falsy value that triggered their return

[gwhitney]

Currently they always convert their outputs to boolean, losing the information of what exactly truthy/falsy value was input. But in many languages, and of a number of arguments returns the first "falsy" argumen, or the last argument if they are all "truthy", whereas or of a number of arguments returns the first "truthy" argument, or the last argument if they are all "falsy". Here "falsy" means "converts to boolean false" and analogously for "truthy". For example, 2 or false would return 2 under this alternate convention. This alternative version of the logical operators can be very useful for producing concise formulas that filter out bad values, avoiding ternaries like x ? x : false and the like. If there was interest in adopting a revised convention, it would be a breaking change, but it would be convenient to implement it along with fixes to #3414.

[josdejong]

I quite like that the boolean operators just return a boolean, it's clear and straightforward.

For your case x ? x : false, I think a new nullish coalescing operator ?? is a very neat solution. That way you can write x ?? false. You've already suggested adding support for that, see #3353.

[gwhitney]

No, x ? x : false is not at all equivalent to x ?? false; the former returns false on all falsy values (0, '', null, etc) and the latter only returns false on null and undefined. They mean different things and have different uses.

There are some strong reasons why most languages that have a notion of truthy and falsy return the actual values from logical operators rather than the strict booleans. For example:

(1) it reduces loss of information in the logical operators. The truthiness/falsiness of the result will be identical, so you will still always be able to use the expression unchanged in a conditional, but you get more information out of the expression, which can be useful. For example, in a long multi-way and/or, you can tell which argument triggered the return (i.e. was falsy/truthy respectively), which you can't do if all you get is true or false.

(2) it allows you to the more concise and easy-to-read logical operators instead of the ternary operator in cases where either you don't actually care about the outcome in one of the two alternatives or you want the entity being tested to be the outcome in one of the two cases. Personally, I find these instances to come up frequently, and I appreciate not having to resort to the ternary operator when it's not really necessary.

And finally, since returning the falsy/truthy operand is what a large majority of languages that have the concept do, changing to that scheme would remove a place where mathjs and MaJE differ from most other programming languages, making them more comfortable for a wide audience to use.

What benefit is mathjs getting from differing from conventional behavior in this aspect and coercing all return values from logical operators strictly to boolean? I don't see any, except possibly that the output type of and on types T and U becomes Boolean instead of T|U. But I don't see that as much practical advantage as the union type is not so hard to deal with and if you really need a boolean you can wrap in boolean() or preface with !!. But you rarely need to, since falsy/truthy values are accepted and behave identically in most places where a boolean value is needed. (As experience in other programming languages shows.)

Is there any chance of reconsideration or do you want to consider this case closed permanently? If the latter just let me know and I will lay off.

[josdejong]

Ah that's true, ?? is different from ? in that it only returns false in case of null or undefined.

In general, to me the case "a or b" is different then "value or default": in the first case you use the operator for what it is intended to do in my opinion: return "truthy" when one of the two values is "truthy". In the second case you use the operator to fallback to a default value when the value is zero or falsy. That feels like a code smell to me, asking for a solution similar to the nullish coalescing operator. A bit off topic, but this reminds me of the "hack" I had to use a lot in React to conditionally render some section of the UI like { condition && <div>...</div> }, which doesn't feel right. I like the explict API of Svelte much better: {#if condition}<div>...</div>{/if}.

Anyway, like you say, returning the first "truthy" value doesn't hurt at all though, and indeed is implemented like that in many programming languages, you have a point there.

Let me give this some more thought, I'll get back to you.

[gwhitney]

I like the explict API of Svelte much better: {#if condition}<div>...</div>{/if}.

Aha, yes, but you see here you are taking advantage of the fact that this conditional has a "binary" form that only requires the condition and the true value. The ternary conditional operator doesn't have that form... well, except: imagine that to cover such cases, we could make the : else part of a ternary expression optional, so you could just write condition ? value when you're only interested in the value when condition is true. Not sure it would be parseable, but presuming it were, there are certainly use cases for it, as your conditional rendering shows (maybe value is actually an expression with side effects).

But then it turns out, this "binary conditional" has exactly the same semantics as and under the pass through falsy/truthy convention! In other words, condition and value is exactly what you want; there's no need for another synonymous operator. Moreover, you automatically get the analogous alternative binary operator (you might want to call unless) that is like a conditional where you only specify the else clause, i.e the value when the condition is false: that's exactly or. This perspective, that and and or are just what you get when you take a conditional and specify just the then clause or just the else clause, is super useful and clarifying -- even for understanding the underlying logical operation itself.

Now of course it is logically plausible that one could have and/or which coerce to actual boolean and analogous binary operators with names more suggestive of conditionals that pass through truthy/falsy values. English grammar makes the word choice difficult, since if(condition, value) and unless(condition, value) would be perfect, but grammatically these should be value if condition and value unless condition when used infix, but the argument order reversal between the forms is confusing (yes python does in fact do it this way, with order reversal, but I find that a pain point). So you'd want words that mean if and unless but with the clauses in the opposite order: for the positive one, condition so value or condition means value or condition implies value or condition produces value; for the negative one condition prevents value or condition blocks value or condition but value. These are all a bit awkward, so I gravitate toward allowing the pass through in and and or and just using them - after all, it is what they mean.

[josdejong]

Thanks Glen. Interesting to think through alternative names for this operation :). I agree the alternatives are a bit awkward. Also, I still haven't been able to come up with any downsides (except that this will be a breaking change in mathjs). So I think it's best not to try to reinvent the wheel and go for letting and and or return the first truthy value instead of returning a boolean, just how it works in many programming languages. You've convinced me 😄👍.