I think Math use of ) vs ] for excluding/including value in range is cleaner than use of =. Is it possible to have something similar in future versions?
So, 1..n can be [1..n) and 1..=n can be [1..n]
Thanks!
Both parentheses and brackets must be balanced in the entire program, even in macros. Not to mention the ambiguities that would be introduced.
14 Likes
In addition, the proposal is merely syntactic sugar for something that already can be done, and succinctly too. So that's another reason not to do this.
11 Likes
Another point of view: even if the already given reasons weren't a factor, i don't like the math syntax. Maybe it makes sense to mathematicians but i could never remember which is inclusive and which isn't. = tells me that it includes (mnemonic: it will equal at the end), and non-inclusive start points don't seem useful enough to require special syntax
This is a subjective stylistic opinion, but the change is itself about stylistic/aesthetic representation, so i think it's valid
1 Like
Granted, I do have a mathematical background, but I always found it pretty intuitive and easy to memorise. When you imagine an interval on the real line, the kink of the square bracket is a reminder that there are points in the interval that are unlike the others in that you cannot move away from them in certain directions without falling out of the interval. In an open interval, all points are the same in that you can move away from any point at some distance in an arbitrary direction, and you will still remain in the set. (This, by the way, is the definition of openness.)
Meanwhile, I will not be the first to point out that a ..= b looks like a compound assignment operator that should mean a = a .. b.
But the point about mismatched brackets being difficult to parse is a valid one. So I would rather have
a <= .. < bfor the interval open on the left,a <= .. <= bfor the one closed on both ends.
It's easy to implement with a macro, by the way.
3 Likes
I'm sorry I didn't get the thing about moving away from a point whatsoever, if you had just told me that it's arbitrary use of brackets or that the parentheses look like they are avoiding the endpoints I'd understand better, but that's neither here nor there.
The compound assignment problem is somewhat of a problem except ranges would appear in places assignment clearly makes no sense, rust never has assignment be an expression, and range equals doesn't make sense. It's a maximum 5 second speed bump the first time you see it and then not really a problem
I'm not on any rust team but I've seen enough discussions about changes to rust syntax to know you'll have to justify why your new syntax should exist (on top of or replacing existing syntax) pretty hard. What's a concrete unavoidable problem with the current syntax that the new syntax solves, and why is it worth a breaking change and/or splitting the ecosystem between old and new
Note that [1..n] is a [Range<_>; 1] today -- a one-element array of ranges -- and while that's not all that useful, it does illustrate that this is a breaking change and thus needs very strong motivation (even over an edition boundary).
11 Likes
What would happen to other tools, like syntax highlighters, if this proposal was accepted? Right now, you can mostly get away with rules like 'strip out comments and quoted strings, and whatever is left needs to balance', which doesn't need any special knowledge of the language1. If you have this kind of construct added to the language, then it will require a lot more language-specific tweaks for what should be simple tools.
Beyond that, this isn't the only way to show inclusion/exclusion. One of my old professors was French, and he said that in French mathematical notation [..) was [..[. Why go for just the Anglo version, why not include the French version as well?
If you really, really want to do this, there is a way of faking it. Rust code is all Unicode, so you can use some of the braces that are higher up in the code planes (e.g. U+207D and up) and a build script that replaces all uses of the special bracket with regular Rust code. I don't recommend this, it's just something you can do.
1 I say 'mostly' because someone is going to come up with a way of breaking this approximation with macros...
2 Likes
Balanced brackets is enforced at the tokenizer level, so there's no way to break that rule. It is theoretically possible for proc macros to make comment contents meaningful, though.
2 Likes
Actually, normal comments are not passed to proc macros, only doc comments are. This can be done with strings, though.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.