Currently Rust has both ".." and "..." for range indication in different contexts.
Range notation ".." is available throughout the language globally as the standard range notation syntax, except for in match pattern ranges. In match patterns "..." is used to match a range of values inclusively (including both of the values specifying the range). In contrast, standard range notation is inclusive of the lower bound, but exclusive of the upper bound. Match pattern notation "..." will not currently work at all in place of range notation ".." or vice versa.
It seems strange that we have two different range syntaxes, with similar meanings, yet completely mutually exclusive use-cases. From what I can guess it seems like this may be related to the use of ".." as wildcard syntax in match statements.
I think we should either extend both syntaxes to each others' specific use-case so they are both usable globally for any range, or abolish one of the syntaxes (probably "..."). As I have mentioned, the overlap with match wildcards might mean another syntactical change to avoid creating syntactical ambiguity. I didn't really know where to start with this as it's a sort of change that might need an RFC, so I thought I'd at least put up an issue to track it and get some feedback.
EDIT:
This would be forward-compatible if both syntaxes are extended to each others' use cases but retain their independent meanings (exclusive and inclusive ranges respectively) so doesn't need to be done pre-1.0.
Currently Rust has both ".." and "..." for range indication in different contexts.
Range notation ".." is available throughout the language globally as the standard range notation syntax, except for in match pattern ranges. In match patterns "..." is used to match a range of values inclusively (including both of the values specifying the range). In contrast, standard range notation is inclusive of the lower bound, but exclusive of the upper bound. Match pattern notation "..." will not currently work at all in place of range notation ".." or vice versa.
It seems strange that we have two different range syntaxes, with similar meanings, yet completely mutually exclusive use-cases. From what I can guess it seems like this may be related to the use of ".." as wildcard syntax in match statements.
I think we should either extend both syntaxes to each others' specific use-case so they are both usable globally for any range, or abolish one of the syntaxes (probably "..."). As I have mentioned, the overlap with match wildcards might mean another syntactical change to avoid creating syntactical ambiguity. I didn't really know where to start with this as it's a sort of change that might need an RFC, so I thought I'd at least put up an issue to track it and get some feedback.
EDIT:
This would be forward-compatible if both syntaxes are extended to each others' use cases but retain their independent meanings (exclusive and inclusive ranges respectively) so doesn't need to be done pre-1.0.