Uses a regular initialized temporary array when sorting elements with an elaborate assignment to avoid undefined behavior when destructors, postblits or copy constructors are invoked during the array assignment.
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.
