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

Clarify the relationships between various kinds of structs and variants #1506

Merged
merged 2 commits into from Aug 12, 2016

Conversation

petrochenkov
Copy link
Contributor

@petrochenkov petrochenkov commented Feb 22, 2016

Provide a simple model describing three kinds of structs and variants and their relationships + some small language extensions following from this model.

Rendered

cc rust-lang/rust#31757 (comment)


As a basic struct, a unit struct can participate in struct expressions `US{}`, including FRU
`US{..s}` and in struct patterns `US{}`/`US{..}`. In both cases the path `US` of the expression
or pattern is looked up in the type namespace.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A unit struct/variant pattern is a struct/variant pattern, not a constant pattern, and therefore is exhaustive.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a "Note 1" below (I could expand it though).

@strega-nil
Copy link

I really like these ideas. If they're not taken up by Rust, I may steal them for my own language :)

Mention type aliases
Mention differences between unit structs / tuple struct constructors and `const` / `fn` items.
Add more use cases for `TS{0: expr}`/`TS{0: pat}`
@alexcrichton alexcrichton added the T-lang Relevant to the language team, which will review and decide on the RFC. label Mar 7, 2016
Fields of a braced struct can be accessed with dot syntax `s.field1`.

Note: struct *variants* are currently defined in the value namespace in addition to type namespace,
there are no particular reasons for this and this is probably temporary.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this is because regular variants are in both namespaces and braced variants are a mistake. However, if we one day get named fields for functions, then I guess we could use struct names as ctor functions, so it might be useful. Too bad that ship has sailed for regular structs.

@petrochenkov
Copy link
Contributor Author

Implementation: rust-lang/rust#35138

@petrochenkov
Copy link
Contributor Author

petrochenkov commented Jul 31, 2016

Note that everything the implementation does (modulo tests and feature gates) is removing non-fatal errors and accepting a new grammar production in the parser, i.e. the RFC only legitimizes things that already work internally.

function calls, but the compiler reserves the right to make observable improvements to them based
on the additional knowledge, that `TS` is a constructor.

Note 1: the automatically assigned field names are quite interesting, they are not identifiers
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This note doesn't appear to be used in the above section.

@nikomatsakis
Copy link
Contributor

Hear ye, hear ye! This RFC is now entering final comment period. In the most recent meeting, @nrc and I (the only two in attendance) both felt inclined to accept (though no final decision has been reached).

In general, the feeling is that this RFC is not needed in any strict sense, though enabling Foo { .. } as a generic "variant check" pattern is pretty useful. It does seem to generally move {} vs () into a more strict relationship, which seems useful, though potentially more confusing (perhaps a stricter separation is clearer?).

@nikomatsakis nikomatsakis added the final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. label Aug 8, 2016
@vitiral
Copy link

vitiral commented Aug 11, 2016

I think making the model easier to understand and more consistent (and without breaking anything) is worth it in its own right. Making macros simpler is pretty awesome too.

The only worry is that there is some future feature that would need this syntax. On the other hand, this RFC makes a pretty clear case that such new syntax would be confusing and non intuitive.

I'm 👍

@vitiral
Copy link

vitiral commented Aug 11, 2016

Also, making TupleStruct just shorthand for NamedStruct but with numeric names makes a lot of sense imo. Not having to do NS(_, _, c, _) is nice as well.

@vitiral
Copy link

vitiral commented Aug 11, 2016

I'm not sure I totally understand the "pattern matching a function" definition though. You can't pattern match to a function, so it is really confusing. I would change that description to something more accurate with how things actually work

@strega-nil
Copy link

I think this is a great change. I agree it's not necessary, but it also seems "good", without much, if any, downside.

@nrc nrc removed the I-nominated label Aug 11, 2016
@aturon
Copy link
Member

aturon commented Aug 11, 2016

I'm very much in favor as well. This is exactly the mental model I want, and I'd love to get rid of the various pedantic restrictions we have today.

@nikomatsakis
Copy link
Contributor

Huzzah! The @rust-lang/lang team has decided to accept this RFC.

@nikomatsakis
Copy link
Contributor

Tracking issue: rust-lang/rust#35626

If you'd like to keep following the development of this feature, please subscribe to that issue, thanks! :)

@Frederik-Baetens
Copy link

Frederik-Baetens commented Dec 27, 2018

Hello, sorry to bother you with this, but the rendered proposal link is broken, I think it should be:

https://github.com/rust-lang/rfcs/blob/master/text/1506-adt-kinds.md

[From the mod: Fixed now.]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-expressions Term language related proposals & ideas A-patterns Pattern matching related proposals & ideas A-syntax Syntax related proposals & ideas final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet