why is position represented with keccak256(owner+tickLower+tickUpper) when owner+tickLower+tickUpper fit inside bytes32? seems like this could work without keccak

Can we just all get along?
Somos todos macacos.
Viva la libertad carajo!

haardik.dev | Founder @learnweb3 | lead instructor /uniswaphooks | building @openfarcaster

Yeah but bytes can be cast to bytes32 without keccak, so it must be something else

Also it doesnt have to be encodePacked it can be simple bit OR and bitshift left

only thing I can think of is `abi.encodePacked` doesn't return a `bytes32` - it returns a dynamic `bytes` data type. keccak'ing it just makes sure the key is always a fixed size bytes32

woah, i think you are right it is possible to pack it 

not sure of the reason why its hashed, maybe since thats how PoolKey did it

hmmm, that's a good point. I dont see any obvious reasons off the top of my head right now - maybe there's larger implications though

tagging @poi who may know more about v4 core's design decisions