Heapify is O(n), extend as currently implemented is O(nlogn). No brainer.
Currently investigating whether extend can just be implemented as a local heapify.
Fixes#12118.
(I sneaked in an unrelated one-character whitespace fix I spotted while reviewing some benchmarks, if that is not okay, I can create a separate pull request for that.)
I don't know if anything else was relying on the old behavior, this seems more correct.
Fixes#16348
If '-F' is allowed to have an optional argument, with the previous version '-FF' would be translated to '-F -F'. In this new version '-FF' translates to '-F' with argument 'F'
Previously, `PrettyEncoder` indented a magic constant of 2 spaces per level, which may be fine for most uses but in my use case I would like to allow the user to specify the indent step for the outputted JSON in my program.
This is small change that does not break any existing code whatsoever, and does not change the behavior of existing uses. `PrettyEncoder::new()` still uses the default of 2.
I couldn't think of any simple tests for this change. The obvious one would be to check the outputted JSON for the correct number of spaces per indent level, but I think that would be more complex than the actual change itself and test little besides correctness and consistency, which can be verified visually. There's already a test for correct parsing of pretty-printed JSON that should still pass with this change.
This enables `num_milliseconds` to return an `i64` again instead of
`Option<i64>`, because it is guaranteed not to overflow.
The Duration range is now rougly 300e6 years (positive and negative),
whereas it was 300e9 years previously. To put these numbers in
perspective, 300e9 years is about 21 times the age of the universe
(according to Wolfram|Alpha). 300e6 years is about 1/15 of the age of
the earth (according to Wolfram|Alpha).
Pros:
I like this example because it's concise without being trivial. The Monty Hall example code is somewhat lengthy and possibly inaccessible to those unfamiliar with probability.
Cons:
The Monty Hall example already exists. Do we need another example? Also, this is probably inaccessible to people who don't know basic geometry.
int/uint aren't considered FFI safe, replace them with the actual type they
represent (i64/u64 or i32/u32). This is a breaking change, but at most a cast
to `uint` or `int` needs to be added.
[breaking-change]
