Crates.io | pluralize |
lib.rs | pluralize |
version | 0.2.1 |
source | src |
created_at | 2020-01-15 02:24:17.272383 |
updated_at | 2020-02-19 06:15:12.391015 |
description | A generic trait across single and multiple elements |
homepage | |
repository | https://github.com/bradymcd/pluralize-rs.git |
max_upload_size | |
id | 198475 |
size | 22,411 |
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.
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 Remover
s 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 Remover
s do. Again, tests to protect you from misbehaviour do exist and you should
heed them if they fail.