I'm only just learning Rust so I don't know much about Rust development, but what are the chances that any of the suggestions listed at the end make it into the language?
I'd love to see RangeInclusive fixed in the manner described. Part of what's blocking such a fix is that we have hard backwards compatibility guarantees. We'd have to do some kind of edition-based transition, where ranges start desugaring to a different type in a new edition than they did in the previous edition. We could do that, and there are various discussions going on to consider such approaches, but we're somewhat hesitant to go down that path.
The problems with Range are well-understood by now, so I don't think that it would be too much of a stretch to argue that a brand-new type could be added to the stdlib with some variation on the semantics given at the end of the post. However, transitioning the dedicated range syntax to that new type would be the tricky part.
Funnily enough, there was a ... syntax for inclusive ranges, but because when looking at code at a glance it is hard to distinguish between .. and ..., it was replaced with the current syntax: ..=
Pretty much zero. All his points are 100% valid, but they're probably annoyances that we can live with, and Range is a really core type - changing it would break basically all Rust code in existence.
New types could be introduced, a..b and other range syntax could resolve to them in next edition and cargo fix could add ".into()" to convert when needed.
