Recursive shape definitions restriction not restrictive enough part 2

[david-perez]

This is a follow-up on #1183.

I guess the phrase "unless one or more members in the path from the container back to itself targets a structure or union shape" needs to be tweaked to mention that the union shape must have more than one member (?).

You can otherwise have recursive unions:

structure AnOperationInputOutput {
    listShape: ListShape
}

list ListShape {
    member: UnionShape
}

union UnionShape {
    member: ListShape
}

But even if you tweaked that sentence, you could still have, more simply:

union RecursiveUnion {
    member: RecursiveUnion
}

So I guess a better way to disallow these is to add another bullet point mentioning that union shapes that refer back to themselves must have more than one member?

[mtdowling]

Ah good point.

The first example is weird, but seems fine to me. The type would end up in PLs like List<UnionShape>. DynamoDB's AttributeValue has recursive union like this for L, for example. It's also not necessarily infinitely recursive when used because a list is bounded and could even have zero length.

The second example is something we shouldn't allow because it's impossible to provide a value for it. Because unions can have many members that refer to themselves, we would want at least one member of the union to not refer directly to itself in order to allow recursive unions.

[david-perez]

I looked at the PR. I think it only addresses direct recursion. This should also be deemed invalid right?

union RecursiveUnion {
    a: RecursiveUnion2,
}

union RecursiveUnion2 {
    b: RecursiveUnion,
}

[mtdowling]

Oh yeah, you’re right. We can follow up here to do a similar path traversal we do with structures.