mmc: Replace .chunks_exact() with .as_chunks() to fix clippy lint

[skr4n]

The latest version of Rust, released just a few days ago introduced a new lint that CI. This PR fixes it.

[rocky]

LGTM - but we should probably bump the version number in Cargo.toml from 0.1.0 to something greater than that and add some sort of dev tag, e.g. 0.1.1dev0, or something like that.

[skr4n]

LGTM - but we should probably bump the version number in Cargo.toml from 0.1.0 to something greater than that and add some sort of dev tag, e.g. 0.1.1dev0, or something like that.

I'd rather avoid the noise with having to do this, given that the Rust tooling does a good job of letting you know about the source of a dependency.

[rocky]

LGTM - but we should probably bump the version number in Cargo.toml from 0.1.0 to something greater than that and add some sort of dev tag, e.g., 0.1.1dev0, or something like that.

I'd rather avoid the noise of having to do this, given that the Rust tooling does a good job of letting you know about the source of a dependency.

I am not sure I understand. There is a version number. 0.1.0 that was released. This is a change to the code, so it is different from version 0.1.0.

If you feel that adding "dev0" is "noise" and want to just call this version 0.1.1 instead, okay. People using or developing the library will track whether 0.1.1 has been released or not.

There is this style of making users/developers figure things out. That seems to be your style. So be it.

[skr4n]

I am not sure I understand. There is a version number. 0.1.0 that was released. This is a change to the code, so it is different from version 0.1.0.

Yes, but these are unpublished changes that are not slated for general use.
Versions only matter for published changes, which can also include nightlies, pre-releases or release candidates (which we do not do).
General users obtain the crate from a published release.

If you feel that adding "dev0" is "noise" and want to just call this version 0.1.1 instead, okay. People using or developing the library will track whether 0.1.1 has been released or not.

0.1.1 and 0.2.0 are ones used for indicating releases that are complete and are not better than using -dev from your prior suggestion.

Moreover, we cannot predict whether our next release would be a breaking one. Bumping the version number before the change would be confusing.

Users looking to track releases have the github releases page, the crates.io page and the changelog file.

There is this style of making users/developers figure things out. That seems to be your style. So be it.

One would opt for a non-published version only for a specific feature that's yet to end up in a release (like we did with libcdio-sys). And to do so, they would most likely obtain it from git.
Looking at the cargo documentation for obtaining a dependency from git, the primary identifier is a commit hash or a git tag rather than the version string, which is precise and would be more helpful in a bug report.

This (bumping the version only before release) is something that all major Rust crates do, without any complaints from users.

The point is, Rust has established tooling and conventions that handle such trivial things for us, which I follow in this crate.

You must be coming from the standpoint of a C project, where things depend a lot on the build system used and the developer's own conventions.

[rocky]

The point is, Rust has established tooling and conventions that handle such trivial things for us, which I follow in this crate.

You must be coming from the standpoint of a C project, where things depend a lot on the build system used and the developer's own conventions.

You are correct, and I stand corrected. Thanks for the information.