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

Vec<!> should be ZST #51524

Closed
vi opened this issue Jun 12, 2018 · 6 comments
Closed

Vec<!> should be ZST #51524

vi opened this issue Jun 12, 2018 · 6 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@vi
Copy link
Contributor

vi commented Jun 12, 2018

#![feature(never_type)]

use std::mem::size_of;

fn main() {
    type V = Vec<!>;
    let v : V = Vec::with_capacity(123);
    println!("{} {} {}",size_of::<Option<!>>(), size_of::<V>(), v.capacity());
}

Expected: 0 0 18446744073709551615
Actual: 0 24 18446744073709551615

Length field is irrelevant, as the vector can be only empty. capacity() getter does not work for ZST anyway, so capacity field is irrelevant too.

Obviously, HashMap and other data structures should collapse to ZST as well when facing the !.

@estebank
Copy link
Contributor

estebank commented Jun 12, 2018

It's not only !, but any ZST that will yield a Vec that takes 24 bytes. I'm pretty sure this is because of Vec's own minimal size: len: usize, cap: usize, ptr: Unique<T> need to be stored in memory, even if it's empty (note that usize is 8, usize + usize + ptr is 24).

@vi
Copy link
Contributor Author

vi commented Jun 12, 2018

Can this useless ballast be optimized away?

Maybe there can be some ConditionalUsize<T> that is like usize for normal types and is like () otherwise. Or even like cap: ForSized<T, usize>, len: ForInhabited<T, usize>, ptr: ForSized<T, Unique<T>,.

@kennytm kennytm added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jun 12, 2018
@sfackler
Copy link
Member

It could in theory be optimized away through specialization, but what's the actual value of doing that? In what context are you working with enough Vec<!>s that 24 "useless" bytes for each matters?

@vi
Copy link
Contributor Author

vi commented Jun 13, 2018

Like with other degenerate cases, probably when code is generated by macros or some other means and relies on heavy optimizer to remove the most of it and retain the meaningful part.

@cuviper
Copy link
Member

cuviper commented Jun 13, 2018

See also #45431.

@Mark-Simulacrum
Copy link
Member

It seems like this is too esoteric and doesn't actually have a concrete use case for us to track, as well as being not entirely clear to me that this is true. Any wins here are likely to be equivalent to #45431 as cited by cuviper.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

6 participants