Skip to content

Defining types that represent native linked lists is hard #1635

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jdm opened this issue Jan 24, 2012 · 2 comments
Closed

Defining types that represent native linked lists is hard #1635

jdm opened this issue Jan 24, 2012 · 2 comments

Comments

@jdm
Copy link
Contributor

jdm commented Jan 24, 2012

type node = {value: i32, next: *node}

This hits the recursive type error, so next has to be *u8 or something else.

@nikomatsakis
Copy link
Contributor

While I agree this is a problem, there is a workaround. Something like this:

enum node = _node; // does this syntax still work?
type _node = { value: i32, next: *node };

ought to work. However, because this is a native linked list, it might not... this is because we get alignment of enums totally wrong. I'm actually not sure what's the best bug representing this issue, but #1535 is certainly a symptom.

@nikomatsakis
Copy link
Contributor

To clarify, the enum node = _node syntax was (maybe still is) shorthand for:

enum node {
    node(_node)
}

Type recursion is permitted through an enum. Single variant enums are supposed to be represented without any discriminant, so this ought to be exactly equivalent to _node. Except that we get the alignment wrong, so it's not exactly equivalent in practice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants