Looks like Rust 1.78 introduced some new clippy lints. I've fixed ours, but looks like wasm-bindgen may need to fix some as well. rustwasm/wasm-bindgen#3945

@himikof How does this look? I'm still waiting to hear back on the intended behavior of the range API.

This change should fix the practical issue, allowing to use the API with large files.

But I still think that the API does not really match the JS from the user point of view, and does not feel like a proper Rust API. In JS, you just specify either some non-empty subset of {offset, length}, or suffix when specifying a request range, and just access the 3 fields (checking them for undefined) when reading a response range.
But in Rust, you must explicitly select one of the enum Variants in the first case (leading to questions like "what is the difference?", "what if I chose the wrong one?"), and even worse, handle all of them in the second case (leading to code duplication). I do not think that to match the JS behavior you need to copy the TypeScript type annotation (which is really an implementation detail many users won't care about) into the Rust API, making it very explicit for all users. Note how the impl TryFrom<R2RangeSys> for Range never constructs OffsetWithOptionalLength with Some length, or OptionalOffsetWithLength with Some offset: those fields are not needed to match JS semantics at all.

Furthermore, this is actually not some Cloudlare-specific API: I would expect it to match the well-known semantics of simple HTTP range header (with only one range). You would expect it to have 3 non-overlapping possibilities: you can requesting a specific range (offset+length), a suffix from the given offset, or a suffix of given length. It is well-known that the range header has this structure, so not having the API reflect this leads to unnecessary surprise.

As this PR already is a breaking change for this API (no implicit integer conversions in Rust), I ask to reconsider changing the Rust enum shape to remove this overlap, and better match the use cases/expectations.

As this PR already is a breaking change for this API (no implicit integer conversions in Rust), I ask to reconsider changing the Rust enum shape to remove this overlap, and better match the use cases/expectations.

I'm waiting to hear back from the team on the actual behavior of these options. Without this information, I do not want to make a decision here.

@himikof I've updated Range to have more clear options / documentation. I did keep 4 options, although you could achieve Prefix using OffsetWithLength { offset: 0, length N }, I think this is more clear.