Circular typedefs in VDL are not compatible with Swift 2.0

[azinman]

It is possible to define a circular typedef in VDL that does not have a legal equivalent in Swift.

For example this legal typedef in VDL:

type RetA []RetA

is equivalent to this illegal typealias in Swift:

typealias RetA = [RetA]

The compiler will complain "Type alias 'RetA' circularly references itself". The reason is a typealias by definition is

typealias name = existing type

and

Type aliases do not create new types; they simply allow a name to refer to an existing type.

In this case RetA is not an existing type. typealias RetA = [RetA?] isn't valid either.

I propose that we go lowest common denominator and not allow this in VDL unless there is a useful scenario for it, in which case perhaps we can isolate that and find a different solution in Swift. In this example RetA is an "infinite mirror" of Arrays and thus meaningless AFAIK.

---

Note this is a separate issue from recursive types in general, which came up on the mailing list likely due to my underspecified subject line. Linked lists, an obviously desirable recursive type, can be implemented in Swift using indirect enums OR classes, but not purely with structs (and indirect structs aren't a priority). At issue is that structs are value types and not pointers/references in Swift. A struct that contains itself has an undefined memory layout do to another "infinite mirror"-type problem.

This is analogous to C where:

// Valid
struct Node {
    void *value;
    struct Node *next;
};

// Invalid
struct Node {
    void *value;
    struct Node next;
};

Note that you can "box" a struct using either a helper class or a private inner enum but that doesn't help us with the typealias issue.

I've taken the vdl struct -> swift enum question offline as it's not appropriate to this issue AFAIK.

[tatatodd]

@bprosnitz @cierniak Adding folks who were interested in the original mailing list post.