[swift-evolution] Discussion: Move range (..., ..<) to a range() function

[Austin Zheng]

... and ..< aren't privileged by the language in any way; they're equivalent to calling Range(start: x, end: y). It would be nice to add more convenience initializers to Range, but I don't want to see the operators go, and I don't think a free function is the best interface.

Austin

> On Dec 8, 2015, at 11:01 AM, Kyle Bashour via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Based on much of the discussion regarding removing C-style for-loops, I'd like to propose a discussion on revamping how range works in Swift. The lack of a reverse range operator and the fact and the range operator and stride() seem to do a lot of the same work have made me wonder why there isn't merely a range() function, as in Python. 
> 
> I believe this would be easier for newcomers to learn, remove the need for stride() (though there are probably use cases for stride() I don't know about, I haven't used it too much), and actually be more clear than ..< and ...
> 
> 
> Here are some examples of how it could work:
> 
> range(10) // equivalent to 0..<10
> range(-1, to: 10) // equivalent to -1..<10
> range(10, through: 0) equivalent to (0...10).reverse()
> range(0, through: 10, by: 2) // equivalent to 0.stride(through: 10, by: 2)
> 
> Or, to avoid a global function, .range() should probably be a function like stride, but with more features (equivalent to above)
> 
> 10.range()
> -1.range(to: 10)
> 10.range(through: 0)
> 0.range(through: 10, by: 2)
> 
> Would love thoughts on why this is good or bad, and if it's worth creating an actual proposal. 
> 
> Regards,
> 
> Kyle
> 
>  _______________________________________________
> 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/20151208/9c8eb1c8/attachment.html>