4 ms·

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

by j4nt4b 6y ago

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?

JoshTriplett 6y ago
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.
- cryptonector 6y ago
  Then again, there's no Rust ABI...
  - kibwen 6y ago
    The lack of a stable Rust ABI doesn't have any relation to the ability to evolve the Range type.
kibwen 6y ago
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.
- theon144 6y ago
  Deprecate two-dot syntax, introduce three-dot syntax? /s
  - estebank 6y ago
    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: ..=
    - Dominear 6y ago
      have you seen this yet https://www.youtube.com/watch?v=xVGO0NIO848 https://www.youtube.com/watch?v=xVGO0NIO848
IshKebab 6y ago
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.
- devit 6y ago
  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.

by j4nt4b 6y ago

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?

JoshTriplett 6y ago

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.

cryptonector 6y ago
Then again, there's no Rust ABI...
- kibwen 6y ago
  The lack of a stable Rust ABI doesn't have any relation to the ability to evolve the Range type.

kibwen 6y ago

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.

theon144 6y ago
Deprecate two-dot syntax, introduce three-dot syntax? /s
- estebank 6y ago
  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: ..=
  - Dominear 6y ago
    have you seen this yet https://www.youtube.com/watch?v=xVGO0NIO848 https://www.youtube.com/watch?v=xVGO0NIO848

IshKebab 6y ago

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.

devit 6y ago
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.