pluralize 0.2.1

A generic trait across single and multiple elements
Documentation
  • Coverage
  • 61.54%
    8 out of 13 items documented0 out of 10 items with examples
  • Size
  • Source code size: 22.26 kB This is the summed size of all the files inside the crates.io package for this release.
  • Documentation size: 3.87 MB This is the summed size of all files generated by rustdoc for all configured targets
  • Ø build duration
  • this release: 9s Average build duration of successful builds.
  • all releases: 9s Average build duration of successful builds in releases after 2024-10-23.
  • Links
  • BradyMcd/pluralize-rs
    0 0 0
  • crates.io
  • Dependencies
  • Versions
  • Owners
  • BradyMcd

Pluralize-rs

Pluralize-rs aims to make generic programming in Rust capable of expressing structures which have a generically quantitied element. A type who has the bounds Pluralize<T> could either be a single primitive T, aOption<T>, or a Vec<T>. A single Pluralize-bound T can be iterated over by calling the pluralize( ) method as can a Pluralize-bound Vec<T> or Option<T>.

The example given in the tests directory is quite reductive, so what is this actually useful for? Imagine you have a perfectly good singly linked list and you want a linked list with multiple link layers. You could just program one, using the singly linked list as a basic template or you could replace your link type (let's call it L) with a generic T: Pluralize<L> and replace your interactions with the link layer with iterators. A little bit of workshopping (to tag the links mostly) and you've repurposed the code for a linked list into essentially a graph (without cycles).
This is the use that I'm programming for, but maybe that will get someone else with more imagination than me off and running with a project either more insane or more practical than that.

Limitations

The technique used to pluralize single primitives is only able to yield ::slice family iterators. You can't to my knowledge adapt this to a more complex structure or iteration scheme, so no ambiguous tree-walking-or-primitive models without substantial work.

Currently the only way to remove from a Pluralize Vec<T> or Option<T> is locked behind the "Remover" feature since Removers rely on casting from a mirrored type with the same layout as slice::IterMut. This is not portable behaviour, realistically anything which effects memory layout could make this code misbehave. There is a test in jank.rs to protect you from this, if it fails something is broken and you shouldn't try to use Removers.

Currently the only way to implement Pluralize over Option<T>' is locked behind the "Options" feature since pulling a slice::Iter out of an Option<T> type requires the same mirrored implementation Removers do. Again, tests to protect you from misbehaviour do exist and you should heed them if they fail.