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.
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]
As of RFC 18, struct layout is undefined. Opting into a C-compatible struct
layout is now down with #[repr(C)]. For consistency, specifying a packed
layout is now also down with #[repr(packed)]. Both can be specified.
To fix errors caused by this, just add #[repr(C)] to the structs, and change
#[packed] to #[repr(packed)]
Closes#14309
[breaking-change]
The last two sections of the guide, and a small conclusion. I suck at conclusions.
I also realized I never covered strings, so I'm going to put that section up before we're actually 'done.'
This appears to be a minor typo. This example implies that x is mutable otherwise the compiler would error on the line before the comment implies.
Please let me know if I'm missing something - I'd love to learn what I got wrong!
It's unfortunate that the read+write operands need special treatment in the AST. A separate vec for all expressions is an alternative, but it doesn't play nicely with trans.
Fixes#14936
A few reasons:
* `Nullable` is basically unused, save for one argument in the `glob` function in `liblibc`, so this change likely impacts nobody negatively. The constructors are never used, and I don't foresee people using them. The people implementing the glob functionality don't seem to be reaching for this POSIX `glob` function, so it seems unlikely to be used heavily.
* At the same time, the old name, `Some`, needlessly conflicted with the same re-exported name in the prelude, which impacted everybody who use glob imports with `libc`. Changing it to something else would simplify things greatly for those people.
* `NotNull` seemed like the best option (others included `Just`, `Valid`, etc. which all had somewhat different connotations than what this type was going for (even `Some` doesn't quite seem like the opposite of `Null`)). Other options included removing the type completely and adding a special, `glob`-specific type. This latter approach doesn't seem future-proof.
Overall, I feel like this is a mildly positive change.
This patch allows json to deserialize integers larger than 2^53 without losing precision. It does this by first keeping the integer portion of a number as a `i64`, and only casting it over to a `f64` if we have a decimal or exponent.
For crates `alloc`–`collections`. This is mostly just updating a few function/method descriptions to use the indicative style.
cc #4361; I’ve sort of assumed that the third-person indicative style has been decided on, but I could update this to use the imperative style if that’s preferred, or even update this to remove all function-style-related changes. (I think that standardising on one thing, even if it’s not the ‘best’ option, is still better than having no standard at all.) The indicative style seems to be more common in the Rust standard library at the moment, especially in the newer modules (e.g. `collections::vec`), more popular in the discussion about it, and also more popular amongst other languages (see https://github.com/rust-lang/rust/issues/4361#issuecomment-33470215).
