What to do in 0.24

[HeroicKatora]

We have collected some amount of cruft that could be fixed in a new major version. There is no single issue that is a pressing concern, some have workaround, but I'd want to arrive at somewhat of a consensus or plan nevertheless as in total it is awkward. In particular the Rust compiler has moved forward quite a bit. I'd make a next branch like last time, which I believe worked out quite well.

The main issues that could be addressed:

Pure renames and restructing

• [x] remove the deprecated top-level decoders, fixing the high-level structure
• [x] remove scream case names, including the ones we missed last time
• [ ] minor renames of functions in imageproc that are now more flexible (#1201)
• [x] Remove empty module math (#1434)

Design issues

• [x] floating point images in DynamicImage, or a rework that would allow addressing this in a future minor change
  • [x] figure out consistent rounding (#1591)
• potentially some improvements with const-generics
• [ ] prepare for potential no_std support, with extern crate alloc;
• [ ] async (#1397) but we'd need a sketch first
• [ ] changes to the GenericImage trait that makes it object safe (#784, #1406, #1118)

Implementation is breaking

• [x] constify some things such as pre-computed tables (#1326)
• [x] fix color accuracy in luma conversion (#1651) (#1215)
• simplify the pixel trait (#1099, #956)
• [ ] fix the API concerns on GenericImage (#1340,
• [x] stream decoders: (#1046, #1219) (#1611)
• [x] troubles with usage of the Seek trait on readers: (#1183)
• [x] fix some clarity issues that require newer compiler (#1333)
• [x] review ImageOutputFormat::Unknown variant (https://github.com/image-rs/image/pull/1453#discussion_r593829446)
• [x] remove 'static bound on Pixel (#1597 )
• [ ] optional get_pixel methods (and more clarity on assert vs. Result)
• [x] This comment in buffer about slice::copy_within usage
• [x] Think about replace and overlay signature (#1575)
• [x] Inconsistent signature in *Encoder::new (#1605)
• [x] DynamicImage as non_exhaustive would be more future-proof

Unanswered questions

• When to do the major version, how to communicate this.
• Which MSRV to choose? Do we want to choose one at all? The alternative could be a build.rs file that enables specific features for specific versions only but I'm somewhat concerned for the testability of such a design. Apart from const-generics, is there any particularly relevant Rust feature that we'd be willing to wait for?
• Any overlooked use case?
• We've also seen some influx of native dependencies (webp, avif). Is there some way in which we can improve our design here, that requires a major version—e.g. feature selection?

[fintelia]

I think it is a good time to start thinking about a 0.24 and I agree with your list of items to consider. Under the first point we should probably also include removal of the deprecated submodules under image::math::* (#1434)

My sense is that the biggest items for this release would/should be iterating the APIs for Pixel, GenericImage and DynamicImage. The async and no_std points could also be quite impactful, but I'm not sure how far we'll be able to get on those in the near term.

[HeroicKatora]

The next branch has been created, and CI enabled. The MSRV limit has also been removed.

[okaneco]

I'd like to see more use of Option and Result return types where feasible to avoid panicking and make interfaces more ergonomic for users. There are several public facing APIs with recoverable states such as get_pixel and get_pixel_mut, ImageBuffer functions that handle Option with expect (but from_vec returns an Option), and functions that assert_[eq]!, some of which do return ImageResult and some don't. More imageops functions should probably return Result or Option. I understand some of these choices may have been made to maintain backwards compatibility.

I know efforts were made for GenericImage::opt_pixel but that was reverted in #1245 and I don't see any issues for it other than #1243 discussing the name. I'd like to see access methods that don't panic in the next version of image. Should I make a new issue to discuss that or use an existing issue like #1243 or #1340?

Another thing I've seen in a TODO in buffer.rs was the 'static bound on Pixel and if that is still necessary there and in imageops.

[HeroicKatora]

Feel free to use #1243 for it. And Ive edited your points into the initial comment.

[HeroicKatora]

Regarding the MSRV policy, how will we handle it and which version should we choose. The situation changed a bit compared to our last choice:

• With Rust 1.56 we have the ability to annotate the supported Rust version in Cargo.toml, making it accessible to yet-to-be-developed tooling. In particular, an MSRV aware resolver is being planned.
• Moving to Edition 2021 is likely a good idea sooner or later.
• The evolution of const is ongoing. This doesn't necessarily affect us directly but it is pretty restrictive to place the same restriction on all dependencies. In particular there are some that can potentially benefit from calculating certain tables, initial state, etc at compile time (jpeg, various decompressors).
• In this irlo thread was discussed using -Z minimal-versions to run the msrv tests. It does not break when new versions of dependencies are released but shouldn't be used in production either. We could also use specific lockfiles instead.
• rustc versions across the Linux Distribution universe:
  • Debian Bullseye released with 1.48.0
  • Debian bookworm is on 1.50 (unstable is naturally on 1.56)
  • Ubuntu 20.04 is on 1.41
  • Ubuntu 21.10 (Impish Indri) is on 1.51, 21.04 (Hirsuite Hippo) is on 1.50

[okaneco]

Under Implementation is breaking, as a sub-point to

[ ] optional get_pixel methods (and more clarity on assert vs. Result)

1500 added functions that returned Option on the ImageBuffer struct in a non-breaking manner but it hasn't been in a patch release for 0.23. Breaking changes would occur if this function was added to traits like GenericImage/GenericImageView or the corresponding functions had their signatures changed.

[5225225]

Should DynamicImage be made NonExhaustive?

Apparently it's not at the moment (Mentioned in #1552), but it looks like the kind of enum we'd want to extend without it being a breaking change.

[jplatte]

Are there plans to do another 0.23.x release? I'm mostly interested because of #1538.

[antonok-edm]

+1 on another 0.23.x release. Looks like there's been a bunch of additions since the last release; in particular I'd love to see https://github.com/image-rs/image/pull/1624 supported in a version on crates.io (https://github.com/jaredforth/webp/issues/7#issuecomment-987693204 for context).