Testing whether a few given values are ordered

[andralex]

Incidentally fixed a doc bug and a few trailing whitespaces in algorithm/comparison.d as well.

[quickfur]

Typo: directly, not dorectly.

[quickfur]

Can we at least split the doc bug and whitespace fixes into a separate commit?

[quickfur]

I still don't like the name ordered.
Why not overload isSorted instead? It's unambiguous, since isSorted takes a single range argument, and so it somewhat makes sense that two or more arguments means you want to compare the arguments among themselves as opposed to looking at elements of the sole argument.

[JesseKPhillips]

assert(ordered(42, 42, 43));

Close to

assert([42, 42, 43].isSorted);

And the allocation could be avoided by providing a range interface for same type tuples; hypothetical

assert(tuple(42, 42, 43).isSorted);

[andralex]

No need to split the commit in two, the comment changes won't show up in some git bisect. tuple(...).isSorted is nice but too verbose to effectively replace sheer comparisons for 3-4 values. I think we should move forward with the name ordered. In fact I'll also add strictlyOrdered.

[andralex]

That brings the question: should we add isStrictlySorted?

[andralex]

doc preview: http://erdani.com/d/phobos-prerelease/std_algorithm_sorting.html#.ordered

[yebblies]

assert(tuple(42, 42, 43).isSorted);

Which is just assert(only(42, 42, 45).isSorted);

[MetaLang]

That doc preview leaves a lot to be desired in terms of readability. Template constraints really need to be grayed out or formatted better or something.

[don-clugston-sociomantic]

I would expect a function called ordered to return true if and only if the parameters have a total ordering.
So I would expect ordered(float.nan, 3.5) to return false, not to throw an assert.
Which is unfortunate because it's a much nicer name than isSorted.

The behaviour would be ideal even for floating point, if "a<b" were replaced with "!(a>=b)" for that case. But that's a bit funky.

[andralex]

only(42, 42, 45).isSorted is nice albeit in all likelihood difficult to make fast enough to be a replacement for comparisons.

[yebblies]

Yes, dmd certainly can't do it.

[MartinNowak]

That brings the question: should we add isStrictlySorted?

Yes, if can't be easily composed, that would be a useful addition.

[JakobOvrum]

Although this is a subset of what can be done with only/Tuple.range (#3198) coupled with isSorted, it is an extremely common use that I agree warrants its own function, both for performance and readability/succinctness purposes, like we did with among (although among is also neat in that allows taking arguments at CT).

LGTM.

[MartinNowak]

Auto-merge toggled on