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
    }

@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