[swift-evolution] Bls: Range that goes both ways

[Mr Bee]

Just to make myself (more) clear, I don't ask for any solutions because I've known them already. I even have made my own custom operators for all the purposes so I have balance operators. Of course they're sugar candy syntax, but isn't that one of the reasons why Swift is great? If you look at previously accepted proposals, some of them are sugar syntax as well. So, I don't think I'm the first one here.
I'm proposing solutions that is built right into the language syntax so everybody else who need such operations doesn't have to make their own custom operators (like me) again and again and again. After all, if there is ..< operator, why can't we have ..> operator too, right? Why should we use the ugly `reversed()` and `stride()` function? If we have to use such `stride()` function that is able to create any possible variations of range, why do we have ... operator in the first place? Isn't it just sugar syntax?
But after I thought about it again, I think half-opened range doesn't really make any senses. The ..< operator (and my proposed ..> operator) should be removed. Or we have to accept the consequences that we also need the other accompanying operators. The … operator with optional `step` attribute that is able to go both ways is more important that half-opened range operator. 
This is all because the lack of c-style for-loop syntax in Swift. Well, I'm not against it, I like it in fact. It makes Swift syntax more elegant. However, I think the range syntax needs to be more flexible and complete as well, so we don't miss the old c-style for-loop syntax.
Regards, 
–Mr Bee
 

    Pada Rabu, 21 September 2016 16:11, Charlie Monroe <charlie at charliemonroe.net> menulis:
 

 Hi,
AFAIK, these all would be very much sugar for:
1) (1 ..< 5).reversed()2) The same as above: (1 ... 5).reversed() does exactly what you want.3) Kind of makes sense to me to include >..,  though to be thorough, you'd need to add >.< as well - that's a weird looking operator...4) There's a global function for this: stride(from: 1, to: 10, by: 2)
Charlie


On Sep 21, 2016, at 9:49 AM, Mr Bee via swift-evolution <swift-evolution at swift.org> wrote:
Hi,
I'm a Swift newbie so forgive me if my question sounds a bit silly, or perhaps had been asked previously. My question is, why Swift doesn't have built-in operator for backward or decremented range? Especially to be used in for-in loop.
Swift only has ... (closed range) and ..< (half-opened range) that both go forward (incremented). To use backward (decremented) range, we have to use several techniques (stride, sequence, etc). Of course those techniques work well. But I don't think they're very swifty, so to say.
So, is it possible to propose a new operator and a modification to existing operator regarding range? Would such proposal be considered and implemented after Swift 3? If it is, here's my pre-proposal about it.
1. Add new ..> operator that goes backward (decremented) as companion to ..< operator that goes forward (incremented).
Example:  for i in 1 ..< 5 { print(i) }will prints: 1 2 3 4  for i in 5 ..> 1 { print(i) }will prints: 5 4 3 2
2. Modify the ... operator to be able to go both ways. If the left operand is greater than the right, it goes backward (decremented). While if the left operand is less than the right, it goes forward (incremented).
Example:  for i in 1 ... 5 { print(i) }will prints: 1 2 3 4 5  for i in 5 ... 1 { print(i) }will prints: 5 4 3 2 1
3. Add new pair of operator to accompany the ..> and ..< (half opened range on the right side) pair operator. It's >.. and <.. operators which are half opened range on the left side. As you might guess, the >.. is the opposite of ..> operator and the <.. is the opposite of the ..< operator.
Example:  for i in 1 <.. 5 { print(i) }will prints: 2 3 4 5  for i in 5 >.. 1 { print(i) }will prints: 4 3 2 1
4. I would like to go even further by introducing a new attribute into for-in loop syntax. It's `step` keyword which is used to define the interval of the loop (like BASIC). Of course this additional attribute only works if the range is countable or indexable. If not, the compiler should complain.
Example:  for i in 1 ... 10 step 2 { print(i) }will prints: 1 3 5 7 9  for i in 10 ... 0 step 2 { print(i) }will prints: 10 8 6 4 2 0  for i in 1 ..< 9 step 3 { print(i) }will prints: 1 3 6   // note: 9 is omitted since it's on the opened side.  for i in 9 >.. 1 step 2 { print(i) }will prints: 7 5 3 1  // note: 9 is omitted since it's on the opened side.
I hope you get the idea. I think such a rich for-in loop syntax would make Swift smarter, more robust, and easier to be learned and understood. They're also required since the flexibiliy of c-style for-loop is no longer available from Swift 3 and on. Decremented or backward range is sometimes needed in some algorithms. Making it built into the language would be better, instead of using non-language solutions. This proposal also doesn't break old codes since it doesn't change the old behavior.
If such proposal is possible to be implemented —or at least considered— in the next version of Swift, I'll do the work of the formal proposal on GitHub. If it's not, well, I don't want to spend my time doing something that will be ignored.
Thank you.
Regards, 
–Mr Bee
PS. I apologize if my English isn't well enough. I hope you all understand what I meant. :)
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution




   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160921/6edd11d5/attachment.html>