
Announcing Rust 1.35.0 - centril
https://blog.rust-lang.org/2019/05/23/Rust-1.35.0.html
======
Shoop
This update comes with a new version of rustup which has much faster updating,
especially on windows [0]. If you'd like to experience this performance
improvements, run `rustup self update` before your upgrade!

[0]
[https://www.reddit.com/r/rust/comments/brtec1/rustup_1183_re...](https://www.reddit.com/r/rust/comments/brtec1/rustup_1183_released/eogpfgr/)

~~~
seeekr
Note for others also unsure of this: `rustup update` also does the self-update
step, only after it first updates the toolchains.

~~~
Shoop
Note that there is an open issue to perform the self-update before the update:
[0]. Could be a good first patch for someone looking to contribute :)

[0] [https://github.com/rust-
lang/rustup.rs/issues/1838](https://github.com/rust-
lang/rustup.rs/issues/1838)

------
haberman
Coming from C++, this always throws me a bit:

    
    
        if (0..=10).contains(&5) {
    

I assume we are taking a ref to "5" (and not passing by value) because "Range"
is a generic type that might be too big to want to copy (or it may not be
copyable at all). But taking a reference to a number for a simple operation
like this feels... weird. It makes me worry that Rust is going to be passing
around pointers to some stack-allocated "5", but I hope that Rust is actually
much smarter than that?

~~~
slx26
what steveklabnik said. if I understand correctly, this is dealing with that 5
as if integers were a generic type. which is the expected "default" behavior
(as in compiler design, not programmer daily use). a generic type would be
stored on the heap, and references there make sense to avoid copies. what
happens here is that integers are special because they are stored in the
stack, they are immutable, and always copied, but this special behavior, which
makes the reference "absurd" here, hasn't been dealt with (yet).

so yeah, it looks super weird, but when you stop to think about it, it's just
that we are so used to integers being "special" that when we see them treated
like a generic type it makes us cringe. interesting.

~~~
comex
This is incorrect. In general, a reference can point to either the stack or
the heap, including when generics are used. It _is_ possible in theory for the
Rust compiler to implement an ABI optimization where function arguments that
are references to small values would be passed by value instead, at least in
some cases (see my other post). However, that optimization does not currently
exist.

Edit: But in this case the reference will be optimized away anyway, because
the callee function will be inlined.

Edit 2: Actually, the optimization does exist at the LLVM level, though it
only applies in some cases. See my other comment:

[https://news.ycombinator.com/item?id=19997818](https://news.ycombinator.com/item?id=19997818)

------
jakobdabo
Coming from C/C++. Is working with the online package manager (Cargo?)
mandatory? Or is there a sustainable way of working/developing with Rust while
completely offline?

I'd like to start a project, manually import libraries (downloaded manually,
no dependency hell), read documentation, etc. Is it possible?

~~~
sanxiyn
You can work completely offline. All official tools support it.

Rust team can't do much about ecosystem though. There are some libraries which
download resource (say, large data table) over the network at build time. I
consider these bugs, but maintainers of those libraries may disagree.

~~~
afureta
Got any examples? I have some spare time and I'd like to improve that
situation.

~~~
sanxiyn
[https://www.reddit.com/r/rust/comments/bki8yo/warning_exists...](https://www.reddit.com/r/rust/comments/bki8yo/warning_exists_in_the_security_risk_of_crate/)
was one recent case.

------
randyrand
Just an idea, instead of printing:

    
    
      [src/main.rs:4] x == 1 = false
      [src/main.rs:9]
    

print this:

    
    
      [src/main.rs:4] dbg!( x == 1 ) = false
      [src/main.rs:9] dbg!
    

Easier to filter just your debug messages.

------
firethief
> Fn* closure traits implemented for Box<dyn Fn* >

This threw me for a minute. Function pointers not using * is confusing enough
without using glob syntax to talk about function types!

~~~
Arnavion
Your comment was also confusing until I reached your parenthetical, because
`+` is used for separating trait bounds :)

~~~
firethief
Yeah, I moved it to the top. Funny how I can't talk about the character being
too overloaded because it has another meaning to the forum...

Edit: the parent comment was replying to an earlier version of my comment, in
which I used + because I didn't know that * could be kind-of escaped by
putting a space after it

------
ridiculous_fish
RangeInclusive is an interesting API:

1\. How does this handle ranges whose length is larger than can be represented
in an integer?

2\. How does iterating a range work for floats? It looks like it just adds one
[1], won't this mean that it will loop forever if the next representable float
is +2?

1: [https://doc.rust-
lang.org/src/core/iter/range.rs.html#297](https://doc.rust-
lang.org/src/core/iter/range.rs.html#297)

~~~
comex
1\. It doesn't.

2\. The Iterator implementation for RangeInclusive requires the underlying
type to implement Step [1], which floats do not. So you can't iterate over a
range of floats (although you can still construct one).

[1] [https://doc.rust-
lang.org/nightly/std/iter/trait.Step.html](https://doc.rust-
lang.org/nightly/std/iter/trait.Step.html)

~~~
ridiculous_fish
What do you mean by "it doesn't?" For example say I construct a range
[INT_MIN, INT_MAX] which should have a length of 2^32. Am I prohibited from
constructing this range?

~~~
comex
I misinterpreted your comment; I thought you meant ranges that were so large
they couldn't fit in any integer type (presumably of floats).

But actually, it's weirder than I thought.

RangeInclusive doesn't have an inherent len() method, but one is provided by
the ExactSizeIterator trait, which is implemented only when the underlying
type is i8, u8, i16, or u16. len() always returns usize, regardless of the
original type; thus I believe the reason for that particular list of types is
that usize is only guaranteed to be at least 16 bits. But I'm not sure why
it's not also implemented for RangeInclusive<usize> and
RangeInclusive<isize>...

~~~
eridius
RangeInclusive is inclusive. This means `0..=0` has a length of 1. Therefore
`0..=usize::MAX` has a length of usize::MAX + 1.

------
Paul-ish
Are there examples of RefMut::map_split? It seems pretty useful if it does
what I think it does.

~~~
comex
The nightly version of the docs properly document that method, including an
example:

[https://doc.rust-
lang.org/nightly/std/cell/struct.RefMut.htm...](https://doc.rust-
lang.org/nightly/std/cell/struct.RefMut.html#method.map_split)

