IntegerView(s)

[oscbyspro]

I need lots of free-function-y stuff to get things done without tying myself to any particular implementation. But free-function-y stuff is messy. The function signatures get way too long or way too terse. It is difficult to track, and tracking preconditions is worse.

So I've been thinking. I might want integer-view-y stuff instead, so things get neatly encapsulated, preconditions get checked on instantiation, and the type system can help out. I imagine these generic over various collections, but I probably need borrowing and consuming for that. I suppose mutable buffer pointers might do.

withStrictUnsignedInteger(...)
withNormalizedUnsignedInteger(...)
SuccinctUnsignedIntegerView(rebasing: view)
NormalizedUnsignedIntegerView(validating: view)

[oscbyspro]

One with...(_:) instead of multiple free-function shims is Greatness™

I have a dream ...of views without closures.

[oscbyspro]

Hm. I've had a hard time getting this to perform well with NBKDoubleWidth (shifts). It appears that NBKStrictBitPattern<UnsafeMutableBufferPointer<UInt>> is slow. I'm not sure why. I got close with NBKStrictBitPattern<UnsafeMutableWords>, however, where UnsafeMutableWords is a custom NBKDoubleWidth pointer.

[oscbyspro]

I'm basically hoping I can turn these into views when Swift gets those, that would be great. Maybe I should still go the custom-NBKDoubleWidth-pointer route until then, because the need for static methods is so silly. Hm. I'll think about it.

[oscbyspro]

So I realized something. Given how binary integers are tree-like, I could wrap sub-views in super-views. Maybe the compiler likes that better than converting back and forth between views? Conversions seem like they might require lots of ownership fiddling that isn't possible in Swift 5.7 or 5.8. Maybe I can do something cool with @dynamicMemberLookup too.

Edit: Doesn't seem like wrapping performs any better or worse (maybe non-pointers care).

Edit: Nope. Nope. Nope. @dynamicMemberLookup turns out to be dynamic. Who'd a thunk it?