[Bug]: Intersection types not supported

[tasosbit]

Description

Intersection types throw error: Non builtin type must have a name

import { Uint32 } from '@algorandfoundation/algorand-typescript/arc4'

type MyAccount = {
  account: Account
}

type WithId = { id: Uint32 }

type MyAccountWithId = MyAccount & WithId

export class HelloWorld extends Contract {
  hello(name: string): MyAccountWithId {
    const account: MyAccountWithId = {
      account: Txn.sender,
      id: new Uint32(13),
    }
    return account
  }
}

Steps to Reproduce

See code above and repro repo here: https://github.com/tasosbit/repro-puya-ts-intersection-types

Expected Behavior

Intersection types work

Screenshots

No response

Device Info

any

Additional Context

No response

[joe-p]

One thing to think about here is how we want the tuple layout to work when fields are overwritten. For example

type MyAccount = {
  account: Account
}

type WithId = { id: Uint32 }

type MyAccountWithId = MyAccount & WithId

Would be (address,uint32).

But...

type MyAccount = {
  id: Uint32
  account: Account
}

type WithId = { id: Uint32 }

type MyAccountWithId = MyAccount & WithId

Should this be (uint32,address) or (address,uint32)?

[iglosiggio]

type MyAccount = {
  id: Uint32
  account: Account
}

type WithId = { id: Uint32 }

type MyAccountWithId = MyAccount & WithId

Should this be (uint32,address) or (address,uint32)?

I would expect A & B = A if B extends A and A & B = B if A extends B. Otherwise the intersection will not be idempotent!

[iglosiggio]

Started looking into this. After solving the weird error message we can at least get these kind of (better) errors:

info: puya-ts 1.0.0
puya 5.7.1
repro.algo.ts:17:11 error: Intersection types are not valid as a variable, parameter, return, or property type. Expression type is {account:Account} & {id:Uint<32>}
                            const account: MyAccountWithId = {
                                  ^~~~~~~
repro.algo.ts:21:12 error: Intersection types are not valid as a variable, parameter, return, or property type. Expression type is {account:Account} & {id:Uint<32>}
                            return account
                                   ^~~~~~~
info: Compilation halted due to errors

and

info: puya-ts 1.0.0
puya 5.7.1
repro.algo.ts:16:3 error: {account:Account} & {id:Uint<32>} cannot be used as an ABI return type
                           hello(name: string): MyAccountWithId {
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
info: Compilation halted due to errors

I would argue that intersection types should not be valid ABI return types (mainly for the same reasons @joe-p commented before). I would be happy to work on supporting them for contract-internal calculations (because the representation there is a lot more malleable, as opposed to ARC4!).

Thoughts?

[joe-p]

I don't think Puya TS has any types that can't currently be returned as ABI types other than the slot-based arrays which are seldomly used.

I think to maximize utility while also avoiding these edge cases the compiler could just throw an error when there is any overlap between the two types.

[iglosiggio]

I think that the typechecker can simplify the types at-will. This makes detecting those situations kinda hard (we would like to use the results of the semantic analysis pass instead of reimplementing our own).

I have a draft branch at iglosiggio/intersections that compiles @tasosbit example but lacks any kind of checks for ill-formed intersections.

[tasosbit]

Could we easily forbid only overlapping intersection types? I think that would clear up the order uncertainty.

[joe-p]

It should be possible. Basically we'd need to search all type declarations and check if its invalid, which shouldn't be too hard or add too much time to compilation. This is how TEALScript checks for invalid uses of number. Rather than checking each type node it visits it does a full search for the number node before running diags or doing anything else: https://github.com/algorandfoundation/tealscript/blob/dev/src/lib/compiler.ts#L2839-L2853

Checking for property overlaps would be a bit more involved because you'd need to follow alias declarations, but it would be the same idea.

[iglosiggio]

I worry that some edgecase might go undetected if tsc simplifies types somewhere.

That said I'll do it on my branch and report back :)

[joe-p]

Yeah I think that's why it's preferable to do a breadth-first search for intersection declarations versus checking if a type is an intersection each time one is visited. If you explicitly search for invalid declarations it's impossible for them to be missed.

[iglosiggio]

I do prefer the latter though. It's correctness it a lot more obvious. An intersection type is valid if:

• All its parts are valid
• All its parts have the same primitive shape (object/number/string/boolean/etc)
• For object-shaped intersections: the property lists of their parts are disjoint

The "checking each time" thing shouldn't be really relevant because the code that does type resolution is backed by a cache (see CacheResolvedType).

[iglosiggio]

Hi all, I found a "workaround" for using intersection types with the current system:

import { Account, Contract, Txn } from '@algorandfoundation/algorand-typescript'
import { Uint32 } from '@algorandfoundation/algorand-typescript/arc4'

type MyAccount = {
  account: Account
}

type WithId = { id: Uint32 }

type MyAccountWithId = MyAccount & WithId

type WithIdMyAccount = WithId & MyAccount

type MyAccountWithId2 = { [k in keyof MyAccountWithId]: MyAccountWithId[k] }
type WithIdMyAccount2 = { [k in keyof WithIdMyAccount]: WithIdMyAccount[k] }

export class HelloWorld extends Contract {
  hello(name: string): WithIdMyAccount2 {
    const account: MyAccountWithId2 = {
      account: Txn.sender,
      id: new Uint32(13),
    }
    return account
  }
}

IMO whatever we do has to be mostly compatible with this hack. This also makes me think that overlapping types shouldn't be banned (but a compiler warning is prolly a good idea!)

[iglosiggio]

I found the original intersection types PR: microsoft/TypeScript#3622
It's nice that it documents the overall design. I feels doable (with some caveats related to reference semantics and mutation)