separate type casting and padding into separate behavior

[mr-zwets]

the current situation of when padding occurs is not very consistent and requires a confusing workaround to cast a bytes item to a certain size

// from int to bytes
bytes(int) -> typecast
bytes6(int) -> padding
bytes(int, 6) -> padding

// from bytes to bytes
bytes6(bytes) -> typecast
bytes6(int(bytes)) -> padding
bytes(int(bytes), 6) -> padding

I suggest a new function toBytesX(item, byteLength) which takes care of the padding

So the new way would be

// from int to bytes
bytes(int) -> typecast
toBytesX(int, 6) -> padding

// from bytes to bytes
bytes6(bytes) -> typecast
toBytesX(bytes, 6) -> padding

possible alternative syntaxes toBytesLength, padBytes, or resizeBytes.

what would break

The second argument in bytes(item, length) would simply be deprecated, this can be done over time, first with a warning.

bytes6(int) would simply be disallowed and result in a type error at compile time, only bytes type would be able to cast to a bounded bytes type

[mr-zwets]

this issue also came up in telegram, raised by @dagurval (https://t.me/CashScriptBCH/423)

int n = int(tx.inputs[0].nftCommitment);
bytes nextCommitment = bytes(n + 1);

cashscript will use OP_NUM2BIN to encode nextCommitment

but what’s the length of the nextCommitment value? will it support full in64 (8 bytes) or will it overflow at some lower number?

I mean OP_NUM2BIN takes two stack items:
number to be converted and the length to encode to

what does cashscript pass as the length to encode to when casting like this “bytes(n + 1)”

ok it looks like a byte-cast is simply a noop, no call to NUM2BIN needed

[dagurval]

My issue was that I assumed bytes cast ment a call to OP_NUM2BIN, but knowing that OP_NUM2BIN takes length as an argument, I didn't know the range of integers it would support. I was concerned that it would default to a small length and my contract would unexpectedly break at some point.

Just documenting bytes( behaviour would be sufficient for my case