My least favorite Rust type

Post by phaylon » Tue, Sep 22, 2020, 5:54 PM UTC

ChrisSD wrote: post #276

ShroudedNight wrote: post #259

Earlier quoted context omitted.

There are a few things: - The big one is that, at least what I see from my admittedly flawed perspective, there appears to be an active annoyance by a significant number of participants on the various issues on the importance of maintaining library ergonomics under constrained execution environments, with bare metal / free-standing environments being an obvious scenario. An example that comes to mind being stuff deal…

That last one is a common enough idea nowadays. Prominent people in every community advocate enforcing code style rules (Douglas Crawford's Javascript linter is famous as an early example and gofmt is practically enforced in the community). The rest of the issues you mentioned are being actively worked on or investigated. Yes Rust 1.0 didn't solve all problems out of the gate and even now there's a lot of work still…

Post by nybble41 » Tue, Sep 22, 2020, 8:03 PM UTC

kibwen wrote: post #76

WhyNott wrote: post #6

I feel like this is an example of what Jonathan Blow calls a "Big Idea" or a "100% solution". His thesis is that when you make a feature of a language too abstract and usable in many different contexts, eventually there will be so many corner cases that the result will almost certainly be clunky and full of footguns. He claims that language designers should aim for "80% solutions" instead, which cover most common usa…

> He claims that language designers should aim for "80% solutions" instead, which cover most common usages but limit themselves enough to avoid complexity. This runs in contrast to a lot of commonly accepted language design wisdom. This is easy enough to say, and indeed I do think it's a good approach, but the problem is identifying that 80% in the first place. The reason that language designers tend to favor general…

Post by timClicks » Wed, Sep 23, 2020, 10:14 AM UTC

floatboth wrote: post #283

timClicks wrote: post #281

Earlier quoted context omitted.

How?

Make the (x..y) syntax construct some std::BetterRange for code in a new edition.

Post by MaulingMonkey » Wed, Sep 23, 2020, 7:54 PM UTC

jiggawatts wrote: post #224

dathinab wrote: post #190

Earlier quoted context omitted.

Interesting: .len() is not the length of a slice induced by the range or the distance between start and end but instead it's the len method form `ExactSizedIterator`, which in turn is a "special case" of where `Iterator.size_hint()` is known to return a correct value. The thing is `Iterator.size_hint()` does return a size, which is usize. So `Range ` can only implement `ExactSizedIterator` on 64-bit targets, which I…

This is another Rust design mistake: conflating the platform pointer size with "lengths". It's possible to process files bigger than 4 GB on 32-bit platforms. It's even possible to memory map them (using sliding windows/views). In some Rust forums, the language designers were shocked to learn that this is possible. At any rate, the Range type was very clearly designed for slices of in-memory contiguous arrays. Then t…

    trait Len64 {
        fn len(&self) -> u64;
    }
    impl Len64 for std::ops::Range {
        fn len(&self) -> u64 { self.end - self.start }
    }
    fn main() {
        println!("{}", (0u32..!0).len());
        println!("{}", (0u64..!0).len());
    }

    4294967295
    18446744073709551615