#pluralize #primitive #generics #programming #derive #macro #linked-list

macro pluralize_derive

A macro to derive primitive Pluralize implementations

1 unstable release

0.1.1 Feb 25, 2020
0.1.0 Feb 24, 2020

#11 in #pluralize

MIT license

3KB

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.

Dependencies

~1.5MB
~38K SLoC