As16 and AddrFrom16 are allocation-free.

Also, I plan to make a new package that unifies the inet.af/netaddr and net/netip with the missing pieces. That'll likewise rely on being able to do zero-alloc conversions back and forth.

allocation-free, but it still copies to the stack, right? Is SSA able to eliminate those somehow?

Still copies to the stack, but it's super cheap. And I'll send a CL soon that'll make it even cheaper. I think this API is fine.

API wise, I was hoping some of those uint128 accessors could somehow get exposed, so I could index bits and and, or, and xor limbs together without having to drop down to bytes or roll it all myself. But I could also understand if that's not desirable in general to do.

I hope we get that via #9455. In the interim, we should copy/paste the uint128 code around as needed. API is impossible to claw back, so for now we should be conservative.

Change https://golang.org/cl/361674 mentions this issue: net/netip: optimize As4 and As16

Alright.

Hopefully the compiler can optimize:

Addr -> endian converstion -> array -> endian conversion -> myu128 -> arithmetic -> myuint128 -> endian conversion -> array -> endian conversion -> Addr

Into

Addr -> arithmetic -> Addr

That seems like an impressive feat though.

Let's see how it does.