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

petrochenkov · 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)

arielb1 · Feb 22, 2016

arielb1 reviewed Feb 22, 2016

View changes

arielb1 · Feb 22, 2016

text/0000-adt-kinds.md

+
+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.


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

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

arielb1 · Feb 22, 2016

arielb1 reviewed Feb 22, 2016

View changes

arielb1 · Feb 22, 2016

text/0000-adt-kinds.md

+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.


Do these have any use?

No. (Not now at least.)
See rust-lang/rust#30882 (comment)

oli-obk · Feb 22, 2016

oli-obk reviewed Feb 22, 2016

View changes

oli-obk · Feb 22, 2016

text/0000-adt-kinds.md

+
+New: Permit tuple structs and tuple variants with 0 fields. This restriction is artificial and can
+be lifted trivially. Macro writers dealing with tuple structs/variants will be happy to get rid of
+this one special case.


examples of crates that had to implement workarounds because of this limitation?

I have an anecdotal evidence from @DanielKeep but no concrete examples so far.

A more subtle question might be crates that are broken, but haven't noticed yet, because nobody tried to make it generate a struct with no fields.

ubsan · Feb 22, 2016

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

nrc · Apr 27, 2016

nrc reviewed Apr 27, 2016

View changes

nrc · Apr 27, 2016

text/0000-adt-kinds.md

+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.


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.

nrc · Apr 27, 2016

nrc reviewed Apr 27, 2016

View changes

nrc · Apr 27, 2016

text/0000-adt-kinds.md

+and a constant with the same name<sup>Note 1</sup>
+
+```
+const US: US = US{};


c.f., an actual braced struct with zero fields, which is not in the value namespace

I think that's the point. An empty struct-defined-with-without-braces is like an empty struct-defined-with-braces, plus a const like this.

nrc · Apr 27, 2016

nrc reviewed Apr 27, 2016

View changes

nrc · Apr 27, 2016

text/0000-adt-kinds.md

+
+Everything related to braced structs and unit structs is already implemented.
+
+New: Permit tuple structs and tuple variants with 0 fields. This restriction is artificial and can


Could you expand on the exact semantics here, I assume there is no interoperability between the different kinds of zero-sized structs. Whereas, a unit struct can be thought of as a single constant object, I would think of zero-field tuple structs generating a potentially infinite number of unique instances, but I can't think of how this makes an actual difference in code.

a unit struct can be thought of as a single constant object, I would think of zero-field tuple structs generating a potentially infinite number of unique instances

Can you expand on your intuition here?

struct TS(); is roughly equivalent to

struct TS { } fn TS() -> TS { TS{} }

, it's described in the section about tuple structs above.

nrc · Apr 27, 2016

nrc reviewed Apr 27, 2016

View changes

nrc · Apr 27, 2016

text/0000-adt-kinds.md

+This also means that `S{..}` patterns can be used to match structures and variants of any kind.
+The desire to have such "match everything" patterns is sometimes expressed given
+that number of fields in structures and variants can change from zero to non-zero and back during
+development.  


This is definitely desirable.

nrc · Apr 27, 2016

nrc reviewed Apr 27, 2016

View changes

nrc · Apr 27, 2016

text/0000-adt-kinds.md

+for braces structs (`ExprStruct`/`PatKind::Struct`), tuple structs
+(`ExprCall`/`PatKind::TupleStruct`) and unit structs (`ExprPath`/`PatKind::Path`). With proposed
+changes `#[derive]` could simplify its logic and always generate braced forms for expressions and
+patterns.


This makes me uncomfortable since it weakens the correspondence between the declaration, pattern, and creation syntaxes. And makes the bracing more fuzzy, where we've been trying to be stricter. Since the only motivation is in procedural macros, I wonder if there is a solution using clever libraries or tooling, rather than changing the language?

petrochenkov · Jul 31, 2016

Implementation: rust-lang/rust#35138

petrochenkov · 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.

Mark-Simulacrum · Jul 31, 2016

Mark-Simulacrum reviewed Jul 31, 2016

View changes

Mark-Simulacrum · Jul 31, 2016

text/0000-adt-kinds.md

+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


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

nikomatsakis · Aug 8, 2016

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?).

vitiral · 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 · 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 · 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

ubsan · Aug 11, 2016

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

aturon · 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 · Aug 12, 2016

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

nikomatsakis · Aug 12, 2016

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 · 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

RFC: Clarify the relationships between various kinds of structs and v…
…ariants

82bb5a0

Some improvements
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}`

433edd9

petrochenkov force-pushed the petrochenkov:adtkinds branch from dfbf8cb to 433edd9 Feb 28, 2016

alexcrichton added the T-lang label Mar 7, 2016

nikomatsakis assigned pnkfelix Mar 10, 2016

petrochenkov referenced this pull request Apr 27, 2016
Closed
Numeric struct fields #1595

aturon added the I-nominated label Jul 28, 2016

petrochenkov referenced this pull request Jul 31, 2016
Merged
Implement RFC 1506 "Clarify the relationships between various kinds of structs and variants" #35138

nikomatsakis added the final-comment-period label Aug 8, 2016

nrc removed the I-nominated label Aug 11, 2016

nikomatsakis referenced this pull request Aug 12, 2016
Closed
Tracking issue for "clarified ADT kinds" (RFC 1506) #35626
2 of 2 tasks complete

nikomatsakis merged commit 433edd9 into rust-lang:master Aug 12, 2016

petrochenkov referenced this pull request Aug 17, 2016
Merged
Fix #[derive] for empty tuple structs/variants #35728

petrochenkov deleted the petrochenkov:adtkinds branch Sep 21, 2016

matthewjasper referenced this pull request Apr 7, 2017
Merged
Document rfc 1506 - clarified adt kinds #37

farodin91 referenced this pull request Jul 21, 2017
Closed
Support rust 1.19 #1491
5 of 5 tasks complete

debris referenced this pull request Jul 24, 2017
Merged
rlp_derive #6125

Centril referenced this pull request Jan 18, 2018
Merged
RFC: Tuple struct construction with `Self(v1, v2, ..)` #2302

Centril added A-syntax A-patterns A-expressions labels Nov 23, 2018

rust-lang/rfcs

Join GitHub today

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

Conversation

petrochenkov commented Feb 22, 2016

arielb1 reviewed Feb 22, 2016 View changes

This comment has been minimized.

This comment has been minimized.

arielb1 reviewed Feb 22, 2016 View changes

This comment has been minimized.

This comment has been minimized.

oli-obk reviewed Feb 22, 2016 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

ubsan commented Feb 22, 2016

petrochenkov force-pushed the petrochenkov:adtkinds branch from dfbf8cb to 433edd9 Feb 28, 2016

alexcrichton added the T-lang label Mar 7, 2016

nikomatsakis assigned pnkfelix Mar 10, 2016

petrochenkov referenced this pull request Apr 27, 2016

nrc reviewed Apr 27, 2016 View changes

This comment has been minimized.

nrc reviewed Apr 27, 2016 View changes

This comment has been minimized.

This comment has been minimized.

nrc reviewed Apr 27, 2016 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

nrc reviewed Apr 27, 2016 View changes

This comment has been minimized.

nrc reviewed Apr 27, 2016 View changes

This comment has been minimized.

aturon added the I-nominated label Jul 28, 2016

petrochenkov referenced this pull request Jul 31, 2016

This comment has been minimized.

petrochenkov commented Jul 31, 2016

This comment has been minimized.

petrochenkov commented Jul 31, 2016 • edited

Mark-Simulacrum reviewed Jul 31, 2016 View changes

This comment has been minimized.

This comment has been minimized.

nikomatsakis commented Aug 8, 2016

nikomatsakis added the final-comment-period label Aug 8, 2016

This comment has been minimized.

vitiral commented Aug 11, 2016

This comment has been minimized.

vitiral commented Aug 11, 2016

This comment has been minimized.

vitiral commented Aug 11, 2016

This comment has been minimized.

ubsan commented Aug 11, 2016

nrc removed the I-nominated label Aug 11, 2016

This comment has been minimized.

aturon commented Aug 11, 2016

This comment has been minimized.

nikomatsakis commented Aug 12, 2016

nikomatsakis referenced this pull request Aug 12, 2016

This comment has been minimized.

nikomatsakis commented Aug 12, 2016

nikomatsakis merged commit 433edd9 into rust-lang:master Aug 12, 2016

petrochenkov referenced this pull request Aug 17, 2016

petrochenkov deleted the petrochenkov:adtkinds branch Sep 21, 2016

matthewjasper referenced this pull request Apr 7, 2017

farodin91 referenced this pull request Jul 21, 2017

debris referenced this pull request Jul 24, 2017

Centril referenced this pull request Jan 18, 2018

Centril added A-syntax A-patterns A-expressions labels Nov 23, 2018

This comment has been minimized.

Frederik-Baetens commented Dec 27, 2018 • edited

arielb1 reviewed Feb 22, 2016

View changes

arielb1 reviewed Feb 22, 2016

View changes

oli-obk reviewed Feb 22, 2016

View changes

petrochenkov force-pushed the petrochenkov:adtkinds branch from `dfbf8cb` to `433edd9` Feb 28, 2016

nrc reviewed Apr 27, 2016

View changes

nrc reviewed Apr 27, 2016

View changes

nrc reviewed Apr 27, 2016

View changes

nrc reviewed Apr 27, 2016

View changes

nrc reviewed Apr 27, 2016

View changes

petrochenkov commented Jul 31, 2016 •

edited

Mark-Simulacrum reviewed Jul 31, 2016

View changes

nikomatsakis merged commit `433edd9` into rust-lang:master Aug 12, 2016

Frederik-Baetens commented Dec 27, 2018 •

edited