`RangeExpression`s with exclusive lower bounds

[GreatApe (Gustaf Kugelberg)]

Ah, I was actually replying to this, it seems the context was lost:

@CTMacUser

That's trivial for Strideable types with an integer stride, but not so much for other types

But regarding the notation question, I'm sure the compiler could make an exception, we already have the ternary operator that is non-standard. OR maybe the requirement can be loosened?

[GreatApe (Gustaf Kugelberg)]

@karim

x>..y and x>.<y Seem more symbolically appropriate to me.

In what way would that be more appropriate? These indicate that your range is smaller than x, which it isn't.

[GreatApe (Gustaf Kugelberg)]

@xwu

The question is whether such a complication can be justified to fill out the lesser used range types—they do have some role but, to be honest, several years after proposing to add them, I don’t miss them.

Well of course they are "lesser used", they don't exist! We could get by perfectly well without the normal greater than sign, not to mention "greater than or equal", and "less than or equal", but I think it would require a very strong argument not to have both. At this very basic level I think symmetry should be the default, and you'd need to motivate any asymmetry, rather than the other way around.

[xwu (Xiaodi Wu)]

@GreatApe

Is there any inherent difference between the lower bound and the upper bound, apart from how they are commonly used?

How they are commonly used is precisely the inherent difference.

@GreatApe

Well of course they are "lesser used", they don't exist!

They do exist, just not in Swift. They are not commonly used, to my knowledge.

@GreatApe

At this very basic level I think symmetry should be the default, and you'd need to motivate any asymmetry, rather than the other way around

Every addition to the standard library must have compelling motivation. Symmetry is not sufficient; in fact, we explicitly reject additions like isNotEmpty, etc. The bar is even higher for new types, and this idea would require not just one but several. The bar is higher still for new operators, and this idea would add not one but multiple infix and unary operators. The bar is highest for changes to the basic syntax of the language. This idea would require such changes too.

[karim (Karim Nassar)]

Meh; yeah, I hadn’t really thought through the comment. I was just reacting aesthetically.

Withdrawn.

[GreatApe (Gustaf Kugelberg)]

@xwu

How they are commonly used is precisely the inherent difference

As far as I can see, it's only different when it comes to arrays and other integer indexed types, and there the difference stems from the way endIndex is defined. Or am I missing something?

@xwu

we explicitly reject additions like isNotEmpty

That's not the same thing. The symmetry between a range that is open downward to one that is open upwards is complete. It's exactly like < vs >.

@xwu

The bar is even higher for new types, and this idea would require not just one but several. The bar is higher still for new operators, and this idea would add not one but multiple infix and unary operators. The bar is highest for changes to the basic syntax of the language. This idea would require such changes too.

This is exactly what I meant by

@GreatApe

Unless there are strong technical reasons

[xwu (Xiaodi Wu)]

@GreatApe

As far as I can see, it's only different when it comes to arrays and other integer indexed types, and there the difference stems from the way endIndex is defined. Or am I missing something?

Yes, you are missing something. It has nothing to do with whether indices are integers or not; endIndex is always defined as the "past the end" index for all collection types and is the fundamental reason why the Swift standard library provides the ..< operator.

@GreatApe

That's not the same thing. The symmetry between a range that is open downward to one that is open upwards is complete. It's exactly like < vs >.

It's not exactly like < and >, for the reason that I have just written above: how they are commonly used is precisely the inherent difference between the existing range operators and the ones discussed here.