Why is the BASE_ASSET_ID type B256 - and not U256?

[IaroslavMazur]

This discussion started as a private conversation between @PaulRBerg and me on Slack, and so, I'll translate & quote our initial replies here.

Iaro: "An argument for switching to U256 is that it'd be, at least, weird to allow the smart contracts to MINT assets having negative ids.

The 2nd one is that it would simplify the work with "asset ids" and "asset amounts"(which are already of type U256) - and make the code more readable."

Paul: "There's no such thing as "negative" numbers in programming, and they only "become" negative if they're interpreted as such (e.g. the two's complement system)"

[IaroslavMazur]

There's no such thing as "negative" numbers in programming, and they only "become" negative if they're interpreted as such (e.g. the two's complement system

While it's true that the minus sign doesn't exist at the low level, it does exist at the level of abstraction of the numerical data types built on top of the low-level bits.

At any rate, I realized that I haven't picked the most appropriate argument for the cause/to explain what I was suggesting. So, let me rephrase.

Data types should be chosen for a reason/because they're suitable for the context. To me, an "unsigned" type sounds the most appropriate for our context of asset ids. At the same time, the B256 type sounds like an overkill.

For reference, here's the description of the B256 type: "A byte array of fixed length ([u8; N]).
This type allows us to more tightly control serialization, deserialization. rlp encoding, decoding, and other type-level attributes for fixed-length byte arrays."

[PaulRBerg]

Thanks for posting this discussion, and for the additional color.

it does exist at the level of abstraction of the numerical data types built on top of the low-level bits

Fair enough

This type allows us to more tightly control serialization, deserialization. rlp encoding, decoding

But we may need to all those thigns. Why do we not need them? An ID sounds like something that needs to be (de)serialized and encoded/ decoded.

[PaulRBerg]

In the grand scheme of things, this is a minor design change, and I'm willing to concede it for purposes of accelerating decision-making.

Feel free to change the type from B256 to U256.

[IaroslavMazur]

But we may need to all those thigns. Why do we not need them? An ID sounds like something that needs to be (de)serialized and encoded/ decoded.

If it needs to be serialized and/or encoded, we can always cast U256 to B256 right before this operation, maintaining the rest of the codebase clean/uniform.

At any rate, U256 seems to be sophisticated enough for what we're doing with the asset ids in the background. At least, for now. If this changes in the future, I'll happily change the type of the asset ids back to B256.

---

I'm willing to concede it for purposes of accelerating decision-making.

Thank you

---

Feel free to change the type from B256 to U256.

Just finished doing this 🙌

[PaulRBerg]

Good points. I changed my mind and I agree that U256 is a better choice.