Implement nominal records

[catamorphism]

We should have nominal records at least as an option, in addition to structural records, whether or not we get rid of structural records.

A nominal record could be declared with record instead of type, like, for example:

record path_ = {global: bool, idents: [ident], types: [@ty]}
   : ast_util::same_len_non_empty(*.idents, *.types);

Constrained types would have to have nominal records (or simpler types) as their base types, not tuples or structural types.

[graydon]

I remain ... unclear on the exact motive for this. Can you elaborate a bit?

[catamorphism]

Without nominal records, it's unclear how to introduce a record literal that has a constrained type. There are also some notes at https://github.com/graydon/rust/wiki/Constrained-types that explain some of the relevant thinking further. With nominal records, the constructor for a record that has a constrained type is analogous to a function with constraints on its arguments, and that way we have constrained types.

Suppose we didn't have nominal records -- consider the record literal {x: 5, y:6}. What is the type of this record? {x: int, y:int}? Or, with constraints: {x:int, y:int} : odd(x), even(y)? Or {x:int, y:int} : lt(x, 6), lt(y, 7)`? Or... of course, an infinite number of possible types. Restricting constrained types to have a nominal record type as their base type lets us assign a unique type to any record literal.

[marijnh]

do this:

tag myname = {field1: int, field2: str};

You now have a nominal record type (myname), that you construct with myname({field1: 10, field2: "hi"}). You can, as long as we have autoderef, then simply do value.field1 on the value, or *value to explicitly get out the record.

[catamorphism]

Marijn: But we don't currently support constraints on variants. The documentation doesn't say anything about it either. I was thinking it might be useful, but that would also be an addition to the language.

[msullivan]

If you declared a nominal record {x: int, y: int} would this prevent you from using the structural record {x: str, y: str} somewhere else? I think we would want an explicit constructor for the nominal record (which might mean we should try to integrate it with single variant tags?).

[catamorphism]

Sully: you're right, my bad. The example declaration should have looked like:

record path_ = P {global: bool, idents: [ident], types: [@ty]}
   : ast_util::same_len_non_empty(*.idents, *.types);

where P would be the name of the constructor in this example. (Don't take the syntax too seriously.) Requiring a constructor is the entire point. That way, any preconditions/postconditions arising from the constraints in the type can get attached to the data constructor.

[graydon]

I tend to favour marijn's suggestion here simply because it errs on the side of minimalism; we can do what you're trying to do here without adding an entirely new type constructor. Can we not just do that?

[catamorphism]

Graydon: what do you think about the comment I directed at Marijn, specifically: "But we don't currently support constraints on variants. The documentation doesn't say anything about it either. I was thinking it might be useful, but that would also be an addition to the language." ?

[graydon]

Sorry, I wasn't clear: I think that (constrained records) sounds like a smaller, easier change, so am requesting / suggesting that rather than a full additional type constructor. It achieves the same end, no? The only penalty is having to write foo({...}) rather than foo { ... }.

[catamorphism]

Oh, I see.

Supposing I write:

tag myname {
      myname ({field1: int, field2: str});
}

does Rust give any guarantees as to the runtime representation of myname? That is, is the eventual plan that the language should guarantee that the compiler won't box the inner product type {field1: int, field2: str} (in other words, will this behave like newtype in Haskell?)

[graydon]

I think if you do tag myname = { ... } then yes. Not sure when it prepends a word of tag-info these days, but in any case it wouldn't box the inner type. At worst just prepend a tag.

[marijnh]

This is already optimized - one-variant tags never store their tag ID

[pcwalton]

If I understand this correctly, a constrained record cannot exist outside of a variant. This means that we would have to divide the universe of types into (all types minus constrained-record) and (all types including constrained record), and variant types would include the latter. This seems more complex to me than just having nominal records.

[catamorphism]

Patrick: I think that's right.

[graydon]

Whatever remains here is, I think, firmly in the bug on implementing classes. Closing as obsolete.