Lantua
July 29, 2023, 6:42pm
35
Anyway, on that note about prior discussions.
There's this very detailed and iterated thread of an idea similar to this one (personally, I'd suggest the entire thread from v1 due to the myriad of good thoughts therein):
Michael Ilseman
Review Manager: TBD
Status: Awaiting review
Implementation:…
This relatively light thread:
These very old threads about combining Range & ClosedRange:
Hello,
Since the release of Swift 3, I’ve seen quite a few people (me included) experience a lot of friction with the new types for representing ranges. I’ve seen people confused when writing an API that takes a Range as argument but then can’t pass in a ClosedRange. Sometimes this can be fixed because the API should be written against a more general protocol, but sometimes that’s not the case.
Those new types definitely seem to cause more problems than they fixed (the Int.max problem). Has th…
I have the impression we exchanged flexibility for correctness (the
ability to represent 0..<Int.max) and that it's wasn't worth the loss
of flexibility.1
Or am I missing something?
Hi people,
I’ve recently started migrating some Swift 2 projects to Swift 3. I
came across the split of Range into Range and ClosedRange and I’ve
really struggled with it. Specifically, in Swift 2, I had a struct
with a Range property that was initialised in many places with
either a closed or open ra…
Tangentially related thread about sugar for index offsetting:
Hello, Swift-Evolution
Using collection indexes are a bit of a bother when you want to do simple slicing and a type is not indexed by Int.
For a simple example take the code here:
let s = "Hello, Swift"
let m = s[...s.index(s.startIndex, offsetBy: 4)]
The intent of advancing startIndex gets a bit muddled.
So to ease this I think we could add startIndex(offsetBy:) and endIndex(offsetBy:) to Collection .
Making the example above:
let s = "Hello, Swift"
let m = s[...s.startIndex(offsetBy: 4)…
8 Likes