That would lead to unpleasant surprises. When calling the function from some loop and when the bounds are inclusive, it's pretty common for (correct) edge cases to exist where you'd call the function with end===start-1. The function would do the right thing by returning an empty set. You'd get duplicate/unexpected records in some cases, that may be hard to debug.

It seems like your approach is just trying to ignore programmer errors, which is rarely a good idea.

▲

roenxi 9 hours ago | parent [-]

I have no horse in the race and would usually just implement my clamp function the way the article does. However, if the clamp function clamping a number is an unpleasant surprise, I'm not going to accept that it is the fault of the clamp function. This hypothetical loop is buggy code and should be rewritten to expect clamp to clamp.

It is a special type of madness if we're supporting a reliance on implementation specific failure modes of the clamp function when someone calls it with incoherent arguments.

	▲	RHSeeger 5 hours ago \| parent [-]
		> This hypothetical loop is buggy code and should be rewritten to expect clamp to clamp. But it makes it harder for the developer to recognize that the code is buggy. More feedback to the developer allows them to write better code, with less bugs. Your argument could be made in the same way to claim that static typing is bad; because the caller should be calling it with the right types of values in the first place.