Navigation Menu

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

Implement "fieldset" optimization for record types #2474

Closed
pcwalton opened this issue Jun 1, 2012 · 5 comments
Closed

Implement "fieldset" optimization for record types #2474

pcwalton opened this issue Jun 1, 2012 · 5 comments
Labels
A-typesystem Area: The type system I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@pcwalton
Copy link
Contributor

pcwalton commented Jun 1, 2012

Currently, record field names are stored as strings in the structural types. This is inefficient; every time we want to define a record in the type table we must perform a string comparison against every field name. Instead we can simply intern an entire "fieldset" -- a list of interned field strings, compared by pointer value only -- as we come across it. Then ty_rec would be something like fieldset, [mt].

@pcdinh
Copy link

pcdinh commented Jan 14, 2013

I learn from Rust 0.5 documentation that record type is gone. Now you call it struct type. Is that correct?

@catamorphism
Copy link
Contributor

@pcdinh Not exactly. Record types and struct types are different. Two record types can be considered the same if the names and types of all their fields are identical and in the same order (that is: they're structurally the same). A struct type has a name that's part of its identity in addition to its fields and types, and two struct types are only considered the same if they refer to the struct type with the same name.

For example, if you write type Point = {x: int, y: int}; type Dot = {x: int, y: int};, you can use values of type Point and Dot interchangeably. But if you write struct Point {x: int, y: int} struct Dot {x: int, y: int}, the compiler will complain if you use a Dot where a Point is expected, or vice versa.

@pcdinh
Copy link

pcdinh commented Jan 14, 2013

Thanks for your clarification. What I read from Rust docs is that I am recommended to use structural type instead of record type because record expression and record types will be removed in a future version.

http://static.rust-lang.org/doc/rust.html#record-expressions
"Note: In future versions of Rust, record expressions and record types will be removed."
http://static.rust-lang.org/doc/rust.html#record-types
"Records are therefore deprecated and will be removed in future versions of Rust. Structure types should be used instead."

Therefore I think that they are identical and can be used interchangeably. It turns out that they are different.

@catamorphism
Copy link
Contributor

I think most people won't see much difference between struct types and record types in practice. There's just the one caveat that I thought I'd mention.

@nikomatsakis
Copy link
Contributor

Now that structural records have been removed and strings are interned, I
don't think that this issue is particularly relevant anymore. There are probably
still improvements to be had here, but I'm going to close the issue. @pcwalton
feel free to re-open if you disagree.

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
also forward --manifest-path to 'cargo metadata'

and then I went on to refactor the argument flag splitting thing a bit, and, uh, that snowballed...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-typesystem Area: The type system I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

No branches or pull requests

4 participants