ratmice / enum_extra Goto Github PK

https://docs.rs/nonzero_ext/latest/nonzero_ext/

currently not all bounds required by MaskIterator are enforced, some are just documented.

A MaskIterator which iterates over unique single bit non-zero enum variants.

Unique single-bit also entails unsigned, or bounded > 0, as the sign lacks uniqueness.
if I recall the implementation correctly it does not need to be contiguous.

It is probably worth enforcing trait bounds for these eventually.

I haven't found the place where default type for enum repr's are given, and what guarantees the compiler gives,
Currently NonZeroRepr requires #[repr(..)] to be set explicitly, and doesn't default to any type.

It appears the compilers though do have a default type, which does not change.
e.g.

enum Foo {
    Bar = std::usize::MAX,
}

error[E0308]: mismatched types
 --> src/main.rs:2:11
  |
2 |     Bar = std::usize::MAX,
  |           ^^^^^^^^^^^^^^^ expected `isize`, found `usize`

and similar for anything attempting to

error[E0308]: mismatched types
 --> src/main.rs:2:11
  |
2 |     Bar = -1_i8,
  |           ^^^^^ expected `isize`, found `i8`

need to find if/where this is guaranteed, before I loosen the restriction...

Ideally it'd be nice to be able to use this with Repr(C) but really idea (with the caveat that I haven't really tried to see if there is actually some sane mechansim) for deciding what type what type Repr(C) would pick.

This whole lib uses a bunch of really strange generic/trait magic (like traits with equality constraints over associated types that are actually Self),

It is worth thinking about how/if it can be simplified: Is it possible to ditch the associated types and merely use Self?
I don't offhand believe so, because we only get equality constraints for traits and they aren't supported in a where clause.

But certainly there seems like a lot of complexity here and it is likely that some simplifications could be made.

For instance, it'd probably be better to rename OpaqueMetadata::Repr to something else so as to avoid inducing ambiguity with EnumMetadata::Repr.

Eventually I want to add traits like SingleBitUnique, ExistsUniqueBit

where ExistsUniqueBit would accept:

  Foo = 0x5,
  Bar = 0x3,

because even though Foo and Bar overlap at bit 1, they are unique in bits 2 and 3.

where SingleUniqueBit
works with enums like:

Foo = 1 << 0,
Bar = 1 << 1,

These are okay, but think if there are better names.
Also its worth thinking whether it should bundle traits together,
for instance MaskIterator wants: NonZeroRepr + SingleBitUnique Should we define a trait which combines these 2 or leave it to MaskIterator to combine the bounds...

Not sure if it is worthwhile, but we could have a type ValidRepr<T> which does not implement arithmetic operators.

It would be constructable from an enum variant and back into an enum variant using to_valid_repr and a variant from_valid_repr would not need to return an option, potentially having an unsafe unchecked constructor.

I'm not certain it is worthwhile though, it is probably worth having a use case in place before adding it.
Potential generic use case: all arithmetic is done in a private function (not publicly, but converting from ValidRepr<T> to the T::Repr), and all cases that arithmetic on T::Repr will produce a T.

by all means chime in if you have a concrete use case for such a thing.