Support list-encoding for structs.

[emiflake]

What is your idea? Provide a use case.

Aiken should support some way to use list-encoding for types rather than Constr encoding.

Currently, when we encode a type, say StakeDatum:

pub type StakeDatum0 {
  stakedAmount: Int,
  delegation: Credential,
  delegatedTo: DelegatedTo,
  lockedBy: LockedBy,
}

This will get encoded as Constr 0 [ ... fields ... ], in cbor, this means it will start with d8799f: [d8 / tag] [79 / 121] [9f / indef array]. But the actual encoding on-chain does not include the first two bytes, it is simply an indefinite length array, 9f.

What I would suggest is that we have some means of encoding it as a list. Borrowing from Rust syntax, we could have:

#[encode(list)]
pub type StakeDatum0 {
  stakedAmount: Int,
  delegation: Credential,
  delegatedTo: DelegatedTo,
  lockedBy: LockedBy,
}

(The exact syntax is not important!)

The frontend of the compiler would still have all of the same behavior as before, with field access and all looking the same, but the underlying encoding would use list.

Why is it a good idea?

The major reason is simple: compatibility. Currently, there are certain datums on the blockchain that cannot be (ergonomically) represented in Aiken. This is problematic because it means older scripts simply cannot be interacted with or expanded on if you're using Aiken. I think this makes the on-boarding experience for Aiken more painful.

Technically, there are also performance benefits of this, since we're wasting the constr tag on nothing when there are no other variants, but this is relatively small.

What is the current alternative and why is it not good enough?

Currently the only way to get this encoding is to use a tuple.

pub type StakeDatum1 = ( Int, Credential, DelegatedTo, LockedBy )

This will get encoded using a polymorphic list, so in cbor/cddl, something like [_ int, foo, bar, baz]. This is what we want! But we are sadly paying the price: we can't give these fields names, and ergonomics suffer drastically.

[rvcas]

@emiflake I'll discuss this with @MicroProofs

We are aware of such an idea but I don't recall why we never bothered.

I want to use that rust style syntax for many things, including this so if this lands, it'll be like as you showed.