Remove structural records #3089
Labels
A-typesystem
Area: The type system
Milestone
Comments
|
Really? Why? Has it been decided to move to nominal for everything? Or does 'structural records' just not mean what I think it means in the context of this issue? |
|
It has been decided. The primary reason is because they don't work well with the new impl coherence rules. In particular, I believe it's not possible to define anonymous impls (that don't fulfill explicit traits) for structural records because no module is responsible for defining the type. |
yjh0502
added a commit
to yjh0502/rust
that referenced
this issue
Feb 27, 2013
The fix is straight-forward, but there are several changes
while fixing the issue.
1) disallow `mut` keyword when making a new struct
In code base, there are following code,
struct Foo { mut a: int };
let a = Foo { mut a: 1 };
This is because of structural record, which is
deprecated corrently (see issue rust-lang#3089) In structural
record, `mut` keyword should be allowd to control
mutability. But without structural record, we don't
need to allow `mut` keyword while constructing struct.
2) disallow structural records in parser level
This is related to 1). With structural records, there
is an ambiguity between empty block and empty struct
To solve the problem, I change parser to stop parsing
structural records. I think this is not a problem,
because structural records are not compiled already.
Misc. issues
There is an ambiguity between empty struct vs. empty match stmt.
with following code,
match x{} {}
Two interpretation is possible, which is listed blow
match (x{}) {} // matching with newly-constructed empty struct
(match x{}) {} // matching with empty enum(or struct) x
// and then empty block
It seems that there is no such code in rust code base, but
there is one test which uses empty match statement:
https://github.com/mozilla/rust/blob/incoming/src/test/run-pass/issue-3037.rs
All other cases could be distinguished with look-ahead,
but this can't be. One possible solution is wrapping with
parentheses when matching with an uninhabited type.
enum what { }
fn match_with_empty(x: what) -> ~str {
match (x) { //use parentheses to remove the ambiguity
}
}
bors
added a commit
that referenced
this issue
Mar 2, 2013
The fix is straight-forward, but there are several changes
while fixing the issue.
1) disallow `mut` keyword when making a new struct
In code base, there are following code,
```rust
struct Foo { mut a: int };
let a = Foo { mut a: 1 };
```
This is because of structural record, which is
deprecated corrently (see issue #3089) In structural
record, `mut` keyword should be allowd to control
mutability. But without structural record, we don't
need to allow `mut` keyword while constructing struct.
2) disallow structural records in parser level
This is related to 1). With structural records, there
is an ambiguity between empty block and empty struct
To solve the problem, I change parser to stop parsing
structural records. I think this is not a problem,
because structural records are not compiled already.
Misc. issues
There is an ambiguity between empty struct vs. empty match stmt.
with following code,
```rust
match x{} {}
```
Two interpretation is possible, which is listed blow
```rust
match (x{}) {} // matching with newly-constructed empty struct
(match x{}) {} // matching with empty enum(or struct) x
// and then empty block
```
It seems that there is no such code in rust code base, but
there is one test which uses empty match statement:
https://github.com/mozilla/rust/blob/incoming/src/test/run-pass/issue-3037.rs
All other cases could be distinguished with look-ahead,
but this can't be. One possible solution is wrapping with
parentheses when matching with an uninhabited type.
```rust
enum what { }
fn match_with_empty(x: what) -> ~str {
match (x) { //use parentheses to remove the ambiguity
}
}
```
|
I think this can be closed now. |
|
Yay! |
bors
pushed a commit
to rust-lang-ci/rust
that referenced
this issue
May 15, 2021
Add format_doc_comments
RalfJung
pushed a commit
to RalfJung/rust
that referenced
this issue
Sep 28, 2023
Automatic sync from rustc
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: