Aiken equivalent for Haskell's newtype

[fallen-icarus]

I'm not sure if this has been discussed before; I have not found any mention of it. I would like to be able to create a type that only exists at compile time. I don't want any unwrapping to occur in production. I just want to leverage the type checker to guarantee I use things properly. The behavior I want is identical to Haskell's newtype where the declared type has the same performance as the underlying type.

As an example use case, I have user identities represented by ByteString but they should not be used the same way. If user 1 is a borrower, then the ByteString for that user id should not be used the same way as user 2, who is a lender. If I could declare something like:

newtype BorrowerId { ByteString }
newtype LenderId { ByteString }

then, I could leverage the compiler's type checking like this:

fn borrower_action( user_id: BorrowerId ) -> Bool {
  ...
}

The compiler should throw an error if I pass in a LenderId, but performance wise, it should be identical to ByteString.

[rvcas]

@fallen-icarus you can do this

opaque type BorrowerId {
  inner: ByteString,
}

https://github.com/aiken-lang/stdlib/blob/97cd61345bcc8925c521b30d0f354859eb0148cd/lib/aiken/dict.ak#L22

[fallen-icarus]

Nice! I just tested it and it does look like it works for my needs. I did not know opaque types 1) have the same uplc representation as the underlying type and 2) unwrapping the type with functions has zero cost. This is exactly what I was looking for. Thanks!

The documentation doesn't seem to have any mention of this, though. Given the resource constraints of smart contracts, I think this should be included in the documentation for opaque types. Specifically, I would include that you can use it to create types that only exist at compile time and are fully optimized away in the uplc. Enforcing invariants is not the only use case.

[rvcas]

@fallen-icarus it's a directly little secret that if the type is opaque and has a single field then it will be zero cost

[fallen-icarus]

I just tried using the latest commit (ad48409) to build my project, but it spit out this error:

        Error aiken::blueprint::interface

  × I caught an opaque type trying to escape
     ╭─[]
 576 │ ) {
 577 │   fn active_beacon_script(redeemer: ActiveBeaconsRedeemer, ctx: ScriptContext) -> Bool {
     ·                           ───────────────┬───────────────
     ·                                          ╰── invalid validator's boundary
 578 │     when redeemer is {
     ╰────
  help: Opaque types cannot figure anywhere in an outward-facing type like a validator's redeemer or datum. This is because an opaque type hides its implementation details, and likely enforce invariants that
        cannot be expressed only structurally. In particular, the opaque type NegotiationID cannot be safely constructed from any Plutus Data.
        
        Hence, opaque types are forbidden from interface points with the off-chain world. Instead, use an intermediate representation and construct the opaque type at runtime using constructors and methods
        provided for that type (e.g. Dict.from_list, Rational.new, ...).

I understand the reasoning behind this, but this breaks the abstraction of a newtype that I was after. Is there any chance this error can be removed or at least converted to a warning? I know I can manually convert the types during runtime, but this opens up a place in my code where the static type system cannot help me.

I've been using opaque types like this extensively since I just want the type separation; I still manually check things when needed. As an example where this really helps, in my datum of 10+ fields, several of them are just PolicyId, and are back-to-back. When I pattern match on the datum to extract out the important fields, I have to double check the ordering is correct before I use them in other functions. If I misuse them, this just results in weird run-time behavior since they are ultimately still PolicyId. By specifying the opaque types in the datum directly, if I get the ordering wrong when pattern matching, the compiler will immediately tell me when I go to use the fields in other functions.

If you really want this restriction, I'd like to suggest that this becomes a warning, and have the warning urge developers to double check they are using it correctly. For example, you could create an UnverifiedId opaque type that must be converted to a VerifiedId opaque type before use in other functions. This would still allow the compiler to help out developers when working with redeemers and datums. Otherwise, I actually think this restriction is doing more harm than good.

[KtorZ]

Is there any chance this error can be removed or at least converted to a warning?

No. This error is rather self explanatory. This actually represent a security risk for your contract (hence the error). You cannot enforce that any user of your contract (e.g. an adversary) will respect the invariants set by your opaque type and could therefore manipulate them in an unexpected way. The type being opaque means that its implementation details are not visible to the compiler and thus, it cannot be deserialized.

So in your particular example, you'd want to have ByteArray in the contract's boundary and turn that into PolicyId using a proper constructor that will check for the invariants.

[fallen-icarus]

This actually represent a security risk for your contract (hence the error).

@KtorZ It is not a security risk because, as I said:

I still manually check things when needed.

I'm not using opaque types to enforce invariants. My main issue is when destructuring a datatype with pattern matching. If I accidentally got the order of the fields wrong, this could lead to run-time bugs. I was asking for a newtype equivalent so that these run-time bugs could turn into type check bugs without incurring a performance cost. But I just went back through the docs and saw that field punning is supported; I guess I missed this the first time I read the docs. That could help so I'll try that out instead.