Post

This blog post is bit of a culmination about me thinking about `n..` ranges in Rust for way too long time. It is about why I think the current semantics for the iterator are wrong. erk.dev/2026/08/30/r...

erk.devRangeFrom, Part 2..: What I think is wrong about the designA trip around my opinions about the RangeFrom type and why I think the iterator has a wrong design

nia (cia asset)

@nia.is.fckn.gay

30 Aug

so this all is a reasonable criticism of semantics but i am deathly terrified of the crater run results should we just try to change this all in-place. ...i will concede that nonzero saturating while the rest overflow is Some Bullshit and we should probably pick one behaviour (saturating imo)

Erk

@erk.dev

Tbh I completely agree, though I am more scared that a crater run would show exactly nothing, since there is not many tests intentionally panicing, (assuming overflow-checks have not been turned off) I think I would personally be more for changing it in the range type which would be more safe imo

30/8/26, 4:37 pm0 reposts3 likes

Lake

@lake.map-rust.com

30 Aug

aren't range type changes for Copy reasons already scheduled or did that already happen

Erk

@erk.dev

30 Aug

They are stabilized (doc.rust-lang.org/stable/std/r...), so it would probably be a breaking change still, just less so since `n..` does not yet desugar to it. Which is scheduled for the next edition.

doc.rust-lang.orgstd::range - RustReplacement range types

Lake

@lake.map-rust.com

30 Aug

New edition that for real fixes range types v2 final final v3 🙏🙏