random.swift

    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
    }

From a performance standpoint, you could eliminate the first map which creates an unnecessary temporary array (although maybe the optimiser can wipe it out ? I have not checked that):

guard let boxedRange = __byteRange else { return nil }

return stride(from: 0, to: boxedRange.count, by: 2).map { rangeIndex in
    let lower = boxedRange[rangeIndex].uint64Value
    let count = boxedRange[rangeIndex + 1].uint64Value
    return Range(uncheckedBounds: (lower: lower, upper: lower + count))
}

As a crazy idea you can try creating custom sequence that consists of pairs and then just map it. It just hides complexity of managing pair values in more cleaner API

public var byteRange: [Range<UInt64>]? {
     // Guaranteed to be in pairs. Example:
     // - 0 : 0
     // - 1 : 71826
     // - 2 : 83948
     // - 3 : 34223
    return __byteRange?
        .map { $0.uint64Value }
        .pairs()
        .map { Range(uncheckedBounds: (lower: $0, upper: $0 + $1)) }
 }

extension Collection where Element == UInt64 {
    func pairs() -> AnySequence<(UInt64, UInt64)> {
        return .init { () -> AnyIterator<(UInt64, UInt64)> in
            var iterator = self.makeIterator()
            return .init {
                guard let first = iterator.next(), let second = iterator.next() else { return nil }
                return (first, second)
            }
        }
    }
}

@fpillet: Beautiful, thank you!
@asiliuk: I'm afraid this looks unmaintainable. Smart but too smart for shipping code.

Here you have my more functional alternative.

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 }
    
    return stride(from: .zero, to: boxedRange.count, by: 2).reduce(into: [Range<UInt64>]()) {
        let lower = boxedRange[$1].uint64Value
        let count = boxedRange[$1 + 1].uint64Value
        $0.append(Range(uncheckedBounds: (lower: lower, upper: lower + count)))
    }
}

@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 of map 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