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

Vector reform #2653

Closed
msullivan opened this issue Jun 20, 2012 · 4 comments
Closed

Vector reform #2653

msullivan opened this issue Jun 20, 2012 · 4 comments
Labels
A-codegen Area: Code generation A-frontend Area: Compiler frontend (errors, parsing and HIR) A-grammar Area: The grammar of Rust A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows A-typesystem Area: The type system C-enhancement Category: An issue proposing an enhancement or a PR with one. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.
Milestone

Comments

@msullivan
Copy link
Contributor

Reform how we handle vectors by introducing a new unboxed dynamically sized vector type and replacing uses of current vectors with boxed dynamically sized vectors.

Syntax still needs to be chosen and we need to determine exactly what restrictions we are going to place on dynamically sized types.

@msullivan
Copy link
Contributor Author

I've become disillusioned with the idea of having real dynamically sized types for vectors. I don't really see any major win. The big thing seems to be that we can make our evec syntax ~[] and @[] in a principled and compositional way.
Even so, a lot of special casing will still be required, and we need to deal with adding a notion of dynamically sized types to the type system and figuring out what operations will be permitted on them. It seems to me that it will increase implementation complexity, not decrease it, and won't provide any real user facing benefit.

I think that what we want to do is leave the type system as is but make ~[] and @[] be special cased to be syntax for evecs.

@graydon
Copy link
Contributor

graydon commented Jun 26, 2012

Also need either a syntax for fixed size interior vectors, or the supertype-of-tuples thing niko suggested, at minimum.

Careful with all type-name substitutions, too.

@graydon
Copy link
Contributor

graydon commented Jun 26, 2012

... And special cases for function environment-capture types.

@msullivan
Copy link
Contributor Author

I think all of the core parts of vector reform are done. I'm going to close the bug.

@msullivan msullivan removed their assignment Jun 16, 2014
RalfJung pushed a commit to RalfJung/rust that referenced this issue Nov 15, 2022
Aaron1011 pushed a commit to Aaron1011/rust that referenced this issue Jan 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation A-frontend Area: Compiler frontend (errors, parsing and HIR) A-grammar Area: The grammar of Rust A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows A-typesystem Area: The type system C-enhancement Category: An issue proposing an enhancement or a PR with one. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.
Projects
None yet
Development

No branches or pull requests

2 participants