Skip to content

E0277 for unions only mentions structs and enum variants #36312

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
apasel422 opened this issue Sep 7, 2016 · 8 comments
Closed

E0277 for unions only mentions structs and enum variants #36312

apasel422 opened this issue Sep 7, 2016 · 8 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@apasel422
Copy link
Contributor

The note issued for the following is "only the last field of a struct or enum variant may have a dynamically sized type," which is confusing, since no struct or enum variant is used:

#![feature(untagged_unions)]

union Foo<T: ?Sized> {
    value: T,
}
@apasel422 apasel422 added the A-diagnostics Area: Messages for errors, warnings, and lints label Sep 7, 2016
@durka
Copy link
Contributor

durka commented Sep 7, 2016

Similar to #36252.

@nagisa
Copy link
Member

nagisa commented Sep 7, 2016

Is there any reason to forbid any (and arbitrary number of) union variant from being dynamically sized? As far as layout is concerned every single field/variant of union is the last.

@apasel422
Copy link
Contributor Author

@nagisa I'd like to see dynamically sized union fields supported as well.

@petrochenkov
Copy link
Contributor

@apasel422

I'd like to see dynamically sized union fields supported as well.

What is the motivation? (Besides "Why not?")
I didn't implement them because enums don't support DST's either, and the union RFC doesn't talk about DSTs and design work (read, one more RFC) is required.

@apasel422
Copy link
Contributor Author

@petrochenkov My original use case was something like:

union Inner<T: ?Sized> {
    value: T,
}

pub struct NoDrop<T: ?Sized>(Inner<T>);

where you want something like Box<NoDrop<Trait>>, which will let the Box's allocation be freed but prevent Trait from being dropped. But now I'm struggling to come up with a reason to do that.

@joshtriplett
Copy link
Member

@petrochenkov Is there any non-trivial design question that arises from putting DSTs in a union, or would they just work in the obvious way? Not arguing against an additional RFC here, just asking if I've missed some unexpected complexity arising from that combination.

@petrochenkov
Copy link
Contributor

petrochenkov commented Jan 3, 2017

@joshtriplett
I don't remember exactly, something about unsizing coercions and how to construct unsized unions (with examples). This coercion business also represented the largest part of implementation work.
+ Something about last/non-last/>1 unsized fields in unions, they are different from structs in this regard.
+ The motivational part, of course.

@steveklabnik steveklabnik added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 9, 2017
@Mark-Simulacrum
Copy link
Member

Aside from the overall question of DSTs in unions, for the time being we should fix the error message here in some way, but I don't know if we have access to whether it's a union or struct at that point -- "last field" for a union doesn't really make sense.

@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 26, 2017
bors added a commit that referenced this issue Aug 18, 2017
…nkov

udpdate error message for unsized union field

Fixes #36312.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants