The emplace() stuff was moved to druntime; for some reason, it's still
in Phobos.
I've diffed the two versions, and they are still almost identical (incl.
unittests); the druntime version appears to have seen some improvements
(e.g., forwarding r/lvalueness of the arguments) in the meantime.
... because it's reordering elements instead. Calling `opAssign` on
unitialized members might also cause errors if the implementation
requires a valid instance (see `TimSortImpl`)
If `-debug` is passed to the compiler, `version(assert)` is true.
TimSort has a `version(assert)` that checks some invariants, and uses
std.format.format for better error messages. Unfortunately, since it
is templated code, this results in Phobos template instantiations of
`format` in the user's code when `-debug` is used.
Given that default dub builds use `-debug`, this is a very common
problem.
Instead of removing the invariant checks, this changes it so they only
happen when testing Phobos itself.
These two functions are related but play two different roles:
std.algorithm.sorting.merge takes a static number of ranges of possibly
disparate types (but compatible elements), and is useful for composing
ranges at compile-time. However, it cannot take a variable number of
ranges at runtime because all ranges must be statically known.
That latter role is played std.algorithm.setops.multiwayMerge, which
takes a range of ranges to merge, and so can merge a variable number of
ranges at runtime. However, because of that, it cannot merge ranges of
disparate types (of compatible elements), and so is unsuitable for
compile-time range composition, unless a workaround like the range class
interface is used.
The docs for these two functions really should cross-reference each
other so that users can more easily find the correct function for their
needs.
add the function nthPermutation that permutates a given range in place n
permutations in O(1).
This is O(n - 1) steps faster than calling nextPermutation n times.
Looks like a search-and-replace messed up the code markup. Also, it seems like the range specified in the second list item was not consistent with its explanation.
This fixes a warning one gets when compiling with warnings enabled:
"phobos/std/algorithm/sorting.d(3122): Warning: calling testcase.foo.__lambda1 without side effects discards return value of type bool, prepend a cast(void) if intentional"
Testcase that fails compilation with `-w`:
```
import std.algorithm.sorting;
auto foo() {
int[] v = [ 25, 7, 9, 2, 0, 5, 21 ];
return topN!((a, b) => a > b)(v, 100);
}
```