to folks:

fn chunks(self, capacity: usize) -> Chunks<Self>

This method will panic if capacity is zero.

So why instead of usize we don't use NonZeroUsize here? Would make the API much more robust, IMO. I'm sure there must be a reason I can't see yet, so any pointer (😱) is appreciated.😄


· · Web · 2 · 2 · 1

@davy Thank you for the pointer, Davy.🙂

Looking into it, they refactored some things regarding the capacity field, but nothing that considers `NonZero` num types in any way, afaik.

> Maybe because the underlying implementation directly uses `Vec::with_capacity` ...

Yes, but this shouldn't block you to create a safe API around it.

See this exemplary playground

@janriemer submit a PR, at best it's an improvement, worst-case scenario you (we?) will get more insights 😅.

@davy Oh, I absolutely will - I'm already on my way. 😄

Thank you for the encouragement.😉

I'll keep you updated.

@davy Issue is out:

but I guess the change won't happen:

After I've written the last sentence(!), I've noticed that std::slice::chunks behaves the exact same way, so in that regard there is symmetry between the two APIs and so:

1. of course std lib can't be changed
2. better to keep symmetry between APIs of Stream and chunks.

Very unfortunate...😢

But anyway, let's see what other Rustanceans have to say to this.🍿

@janriemer Indeed! But at least we now have a clear answer, thanks for digging into this ♥️.

Probably was the function introduced before the type was stable?

@musicmatze Yeah, that's a good idea.

There a several issues in different repos which propose the same thing, but it is denied, e.g.:

Some argue, it is not idiomatic Rust and not intended for APIs, which is a shame IMO:

Also, I was pointed to the following feature, which, if it lands, could help, but I'm sceptical:


Sign in to participate in the conversation
Mastodon for Tech Folks is shutting down by the end of 2022. Please migrate your data immediately. This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!