ordering of parameters makes isBetween a non-starter

[michaelficarra]

Nobody is ever going to remember the order of parameters for isBetween. Without looking, if I had to guess at an order, it would be "lower bound", "upper bound", then the number being tested. Actually, I lied because I would expect the bounds to be given in either order ("between" works both ways in English). I don't see a way this could ever be resolved, and that's not even touching upon the inclusivity question of the bounds. I suggest you abandon isBetween and go with the alternative suggestion of an isIncreasing (or isNotDecreasing) and isStrictlyIncreasing function.

[ljharb]

I would expect (target, min, max), or (min, target, max) as if min <= target <= max - never target being last.

[ljharb]

One possibility would be Number.prototype.isBetween(min, max), though.

[michaelficarra]

@ljharb Then you still have to resolve the issue with "between" implying no bounds order and the inclusivity issue. It's not worth going that route.

[ljharb]

True. "is between" to me implies it's exclusive on both ends, though, and "order" would be LTR.

[js-choi]

Thank you for the feedback; I am ready to drop isBetween and switch to the isIncreasing approach. I’d still like to get a quick temperate check at plenary if this achieves Stage 1.

The isStrictlyIncreasing name (versus having isIncreasing take a boolean) is a good idea, and I’ll add it as an option later.