Findings:
1) Far more people prefer inclusive than I would have thought. I guess this is thanks to Ruby/Perl?
2) It's still highly ambiguous and so probably shouldn't choose to use this syntax at all...
Conversation
How do folks feel about a..=b and a..<b for inclusive and exclusive respectively? :troll face: / serious question
7
2
I like Swift's `a..b` and `a..<b`. Rust got it round the wrong way.
If you want to use the equals sign then I only accept `a=..=b` and `a=..<b`, but now it looks like I've got weird smileys everywhere.
1
1
I would love to see a gradual migration in Rust to Swift's approach over multiple editions (via your proposal), but I doubt there's any energy to spare for that.
1
Why do you feel so strongly that inclusive is the right default/unadorned syntax?
1
Because asymmetrical ranges should use an asymmetrical operator. Symmetrical ranges should be symmetrical. It's likely I could be a weirdo though and maybe if I thought more about it I'd feel less strongly. 😅
1
There's an argument probably from `[n, m)` is used more often in programming, so it should have the least syntactic weight, but I dunno if I really agree.
Replying to
My experience is that half-open ranges are most useful for slicing and closed ranges are most useful for matching/parsing.
For example, you it's not even obvious how one would represent 'a'..'z' (the class of english alphabet characters) with a half-open interval.
1
2
Yeah, that's a neat observation.
It has bugged me in the past that Rust treats these uses of ranges differently :(