-
-
Save steipete/e2ed747f41e0148de9cfb21e0e99908b to your computer and use it in GitHub Desktop.
public var byteRange: [Range<UInt64>]? { | |
// Guaranteed to be in pairs. Example: | |
// - 0 : 0 | |
// - 1 : 71826 | |
// - 2 : 83948 | |
// - 3 : 34223 | |
guard let boxedRange = __byteRange else { return nil } | |
let range = boxedRange.map { $0.uint64Value } | |
var ranges: [Range<UInt64>] = [] | |
for rangeIndex in stride(from: 0, to: range.count, by: 2) { | |
let lower = range[rangeIndex] | |
let count = range[rangeIndex + 1] | |
ranges.append(Range(uncheckedBounds: (lower: lower, upper: lower + count))) | |
} | |
return ranges | |
} |
@fjtrujy using reduce
here doesn't bring any improvement in clarity, maintainability or speed IMHO. The advantage of map
is that it's straightforward to read the code and understand what it does.
@fjtrujy using
reduce
here doesn't bring any improvement in clarity, maintainability or speed IMHO. The advantage ofmap
is that it's straightforward to read the code and understand what it does.
Yes, you're totally right, I was thinking to use the "reduce" at the very beginning because I was thinking to discard the "even" values while iterating, but at the end, the discard of the values is better implemented with the stride
.
Not sure if this meets the bar of readability and maintainability but personally I think it improves readability to define fluent extensions:
extension Swift.ClosedRange where Bound: Strideable {
func by(_ strideAmount: Bound.Stride) -> StrideThrough<Bound> {
return stride(from: lowerBound, through: upperBound, by: strideAmount)
}
}
extension Swift.Range where Bound: Strideable {
func by(_ strideAmount: Bound.Stride) -> StrideTo<Bound> {
return stride(from: lowerBound, to: upperBound, by: strideAmount)
}
}
for rangeIndex in (0...7).by(2) {
// reads as 0 through 7 by 2
}
for rangeIndex in (0..<7).by(2) {
// reads as 0 to 7 by 2
}
I think it's mildly easier to parse visually than the stride initializer
Here you have my more functional alternative.