ARC-43 No Length in Dynamic Arrays of Static Types

[joe-p]

Proposes the removal of element length prefix on non-nested static types.

This alone is not super important, but if we are making breaking changes to the ABI might as well include this QOL change.

[jannotti]

This proposal presumes that the decoder knows where the value ends. But the ABI was designed to allow decoding by walking along without knowing ahead of time where the end of a value is. PR #212 would break that design, and require extra encoding bytes, and then this PR would work. But, why would we do PR #212 which adds encoding bytes so that we can do this PR, which removes some?

[joe-p]

But the ABI was designed to allow decoding by walking along without knowing ahead of time where the end of a value is

What's the value of this? In what scenarios will a decoder not know how long the data its decoding is?

But, why would we do PR #212 which adds encoding bytes so that we can do this PR, which removes some?

The byte savings isn't really the main motivation. It's mostly opcode savings. Not needing to extract/add len when working with bytes/strings and also just being able to concat to add to an array rather than concat + increment prefix

[jannotti]

But the ABI was designed to allow decoding by walking along without knowing ahead of time where the end of a value is

What's the value of this? In what scenarios will a decoder not know how long the data its decoding is?

It's exactly the property you need so that PR #212 is not needed. You don't have to know how much of the input remains to be decoded, so you don't have to substring out the value to decode it.

[joe-p]

It's exactly the property you need so that PR #212 is not needed. You don't have to know how much of the input remains to be decoded, so you don't have to substring out the value to decode it.

The use case #212 is trying to solve is extracting a value from a tuple without decoding the entire structure. I would think that's a much more common use-case than fully decoding the entire tuple every time you want to read one element.

[joe-p]

In the public discord ARC meeting this seemed to be unanimously supported.

[jannotti]

So this is only for top-level objects, right? The ARC says: The exception is if the array is encoded inside of a tuple. but also mean when encoding in a dynamic array, right? (since the encoding of a dynamic array itself encodes the tail as a tuple).

So we're talking the individual values in ApplicationArgs[0-15] only?

[joe-p]

So this is only for top-level objects, right? The ARC says: The exception is if the array is encoded inside of a tuple. but also mean when encoding in a dynamic array, right? (since the encoding of a dynamic array itself encodes the tail as a tuple).

So we're talking the individual values in ApplicationArgs[0-15] only?

Exactly, I will clarify this in the ARC.

[joe-p]

I just realized that this introduces weirdness with bool[]. Given a top-level bool[] encoded as 0x00 there is no way to know how many boolean values are actually encoded.

Personally, I'd prefer to just change booleans to be encoded as 0x01 and 0x00 for reasons beyond this ARC, but the alternative is that booleans are always prefixed with their length