Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Rust 1.35.0

blog.rust-lang.org

Post reply on HN
Print view View original

61–70 of 111 posts

Re: Announcing Rust 1.35.0

#61

Post by ACow_Adonis »

gfs wrote: post #48
jakobdabo wrote: post #43

Earlier quoted context omitted.

Thank your for the detailed answer. > Attempting to do it completely manually has no benefit that I can see Package managers and build tools can do basically whatever they want - run commands, execute binaries, download data, upload data, send telemetry - whatever any one of the package maintainers wants. I prefer to develop in an offline VM. When a new library is required I just download it using the host machine, c…

I totally understand your desire to develop things in a sandboxed environment but the source code for Rust/Cargo/Etc. is all available under their organization at GitHub. [0] It would be easy to audit and raise issues if you have any concerns. [0]: https://github.com/rust-lang

I know if no language or situation beyond the academically trivial where I would describe auditing source, open or otherwise, as easy.

Re: Announcing Rust 1.35.0

#62

Post by afureta »

haberman wrote: post #31

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 "…

It's because the std::ops::RangeInclusive struct is meant to be much more generic than just ranges over machine-sized integers. I think a generic range struct in C++ would similarly take references.

Re: Announcing Rust 1.35.0

#63

Post by afureta »

sanxiyn wrote: post #28
jakobdabo wrote: post #19

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?

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.

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

Re: Announcing Rust 1.35.0

#64

Post by afureta »

Avamander wrote: post #50
mrath wrote: post #17

Earlier quoted context omitted.

I think some would have reacted exactly with other await syntax proposals. The amount of feedback they got is overwhelming. I believe all of the unique ideas are all looked into by the team. The Lang team is doing a great job. all I wish now is to slow down and not grow the language to C++ levels.

I wish they spent time at making the code a tad bit less symbol-ic and more verb-ic, the amount of nonalphabetic symbols used is just immense and it's not easy to decipher quickly. C++ suffers from the same issue I think.

Honestly, it's not that big a deal, in my opinion. Firstly, it looks much better, since the operators, i e. the ideas I'm most familiar with, take up the least space. Secondly (and more stupidly), millions of programmers don't even know English and they've managed to get by with ifs and elses, so I'm sure we'll manage.

Re: Announcing Rust 1.35.0

#66

Post by 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

Re: Announcing Rust 1.35.0

#67

Post by comex »

steveklabnik wrote: post #59
haberman wrote: post #55

Earlier quoted context omitted.

Will the calling convention pass this by value even if it isn't inlined? My hope is that the ABI would systematically decide: "passing a const ref to a type that fits in a machine word is silly, so we never do that."

I think so, but am not sure. The spec answer is “who knows” because it’s not defined, but practically I’m not 100% sure if the compiler does it always today.

No, it never does that optimization:

https://play.rust-lang.org/?version=stable&mode=release&edit...

(see assembly output)

Edit 2: I lied: Rust doesn't perform such an optimization but LLVM does, -argpromote. But it only works if the callee is compiled in the same LLVM module as the caller (or with non-thin LTO), and is not visible outside that module. And since it has to respect pointer identity, it only works in a subset of cases.

Original post:

It arguably cannot, because you can cast the reference to a raw pointer and compare it to other pointers, though I don't think there's been a proper discussion on whether or not references are guaranteed to preserve pointer identity.

Edit 1: However, Rust's compilation model does theoretically allow the compiler to modify a function's ABI based on its implementation, at least in some cases, so it could theoretically perform the optimization only when calling functions which it knows don't care about pointer identity. That would avoid violating the aforementioned guarantee that may or may not exist, but it would be less reliable, as the compiler's analysis would inevitably lose track of some pointer values and treat them as escaping, thus potentially identity-sensitive, when they're actually not.

Re: Announcing Rust 1.35.0

#68

Post by comex »

slx26 wrote: post #44
haberman wrote: post #31

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 "…

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 copi…

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

Re: Announcing Rust 1.35.0

#69

Post by comex »

ridiculous_fish wrote: post #66

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

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

Re: Announcing Rust 1.35.0

#70

Post by willglynn »

ridiculous_fish wrote: post #66

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

Note this bit:

    impl Iterator for ops::RangeInclusive {
RangeInclusive implements Iterator only for types A which implement Step. Floating point types like f64 are not Step:

https://doc.rust-lang.org/std/iter/trait.Step.html

Thus RangeInclusive is perfectly valid, but RangeInclusive cannot be used as an Iterator.

See also the bounds on contains():

https://doc.rust-lang.org/std/ops/struct.RangeInclusive.html...

f64 is PartialOrd, so a RangeInclusive can be asked if it contains a specified f64. This definition would also allow one to ask a RangeInclusive if it contains a specified IpAddr _or_ Ipv4Addr _or_ Ipv6Addr, since IpAddr is PartialOrd, PartialOrd, and PartialOrd.

Any type A which can be compared to any other type B automatically gets RangeInclusive::contains(B). Anything which doesn't can still be a RangeInclusive, it just won't have contains().

Post reply on HN