pluralize

Crates.iopluralize
lib.rspluralize
version0.2.1
sourcesrc
created_at2020-01-15 02:24:17.272383
updated_at2020-02-19 06:15:12.391015
descriptionA generic trait across single and multiple elements
homepage
repositoryhttps://github.com/bradymcd/pluralize-rs.git
max_upload_size
id198475
size22,411
Brady (BradyMcd)

documentation

README

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.

Commit count: 20

cargo fmt