[Pre-RFC] use ... instead of .. in pattern ellisions

internals bikeshed (deprecated)
1

Hey, I felt this would be nice, because ... is actually used for elision, so it is more consistent than the current method. Heres the RFC:

I would be willing to make the changes to the libraries, but I do not know enough about compiler internals to make the most necessary changes.

2 Likes
2

I agree on the basis that ... is what I immediately think of for this purpose in general. It also makes slightly more sense in that you’re eliding everything, not everything except the last thing.

I disagree on the basis that there might be a lot of code to have to update for a relatively minor change.

I suppose it comes down to “how easy would this change be to make?” I don’t know the answer to that.

3

I believe we will eventually support a ... b (if we don’t already) as the syntax for inclusive ranges. So the motivation for this change seems limited, since it won’t really be avoiding overlap with an expression form (nor with a pattern form, since a..b is a range). In general I have a vague preference for ... as well, but I’d prefer to avoid gratuitous changes to the surface syntax that are not motivated by something other than aesthetics. (Another alternative would be to go back to * instead of ...) Note that .. also appears in struct patterns Foo { a: _, ..}).

(That said, I would consider a change to the “inclusive range” syntax, since that seems ripe for confusion and typo-based bugs. On IRC something like a..b (exclusive) and a..=b (inclusive) was proposed.)

4

@DanielKeep: I was trying to be conservative :slight_smile: I remember looking into some random file in rustc code, and saw a match on a enum with lots of ThisKindOfType(..) => { }, ThatKindOfType(..) => { }, over and over. I wish my grep foo was good enough to run some kind of test to see how much code this would affect. In general though, +1?

@nikomatsakis: I would not say it is just a change to surface syntax, ... has the meaning that we are looking for, not .., but I see what you mean. And yes, I was also including the struct pattern ellison, did not mention it though.

We do not even need inclusive range syntax, in my opinion. Python gets by just fine without it.

In general though, niko, +1 to the idea? Do you think I should post this (along with adding a mention of the struct ellison syntax change) to the RFCs repo?

5

Well, I'm positive, but I'm not sure I'm at +1. Maybe +0.25? Like I said, out of context, I think it's a good change... but it's not necessary, and it could be quite churny.

6

I agree, I do not think that I would be happy if I did not try :slight_smile: I probably should have submitted this and a couple of my other nits proposals earlier before alpha

7

Never mind, i no longer have any intentions of working on this.

8

There are two reasons that I think inclusive range syntax is useful

  1. Pattern matching like match char { 'a' ... 'x' => ... }
  2. Unsigned ranges like 0 ... MAX+INT
9

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.