Skip to content
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

Allow recursive untagged unions #1804

Closed
spinda opened this issue Nov 29, 2016 · 9 comments
Closed

Allow recursive untagged unions #1804

spinda opened this issue Nov 29, 2016 · 9 comments
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.

Comments

@spinda
Copy link

spinda commented Nov 29, 2016

The current implementation of RFC #1444 disallows the following:

#![feature(untagged_unions)]

union Foo {
    f0: u8,
    f1: Foo,
}
error[E0072]: recursive type `Foo` has infinite size
 --> <anon>:3:1
  |
3 | union Foo {
  | ^ recursive type has infinite size
  |
  = help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `Foo` representable

Unlike structs, since all fields of a union exist in the same space, a union whose definition involves infinite recursion can be represented in finite space. In this case, Foo can be represented as union { f0: u8 }, with &foo.f1 equivalent to &foo.

@ranma42
Copy link
Contributor

ranma42 commented Nov 29, 2016

What is the use case? As you mentioned in your comment, it looks like it would only provide a different (and more verbose) name to the same data.
An alternative could involve improving the error so that instead of infinite size it complains about the almost-useless self-referential field.

@spinda
Copy link
Author

spinda commented Nov 29, 2016

My use case is generic unions generated by a macro, of the form:

union Foo<A, B> {
    a: A,
    b: B,
}

Foo<A, Foo<B, C>> is a type whose size is the maximum of the sizes of A, B, and C. Sometimes this ends up producing a recursive union definition, and instead of quietly accepting it, rustc raises an unnecessary error.

@oli-obk
Copy link
Contributor

oli-obk commented Nov 29, 2016

related: #1151 (recursive enums)

@nrc nrc added the T-lang Relevant to the language team, which will review and decide on the RFC. label Dec 19, 2016
@joshtriplett
Copy link
Member

@spinda It seems like the generic types there should eliminate the circularity. A Foo can't unconditionally contain a Foo, but it can contain a T and a user can map that T to a different Foo type; that doesn't create a loop. I wonder what makes the compiler think it does?

Can you post a concrete code example with a macro invocation that produces the error?

@spinda
Copy link
Author

spinda commented Jan 26, 2017

@joshtriplett Hrm... In the months since I submitted this, I changed my approach to the project that needed it, and now I can't recall a specific example. I'd be okay with closing this.

@vcfxb
Copy link

vcfxb commented Nov 6, 2017

@spinda I'm trying to get around this right now, how did you change your approach?

@Centril
Copy link
Contributor

Centril commented Jan 17, 2018

Triaging this issue: @spinda Are you interested in this still?

@spinda
Copy link
Author

spinda commented Jul 4, 2018

@Centril I'm late here, but no, not really. Moved on to other things.

@Centril
Copy link
Contributor

Centril commented Jul 4, 2018

Alright. Closing this then.

@Centril Centril closed this as completed Jul 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

7 participants