Same introducer for anonymous vs. nominal types?

[josh11b]

Context for this question is the struct proposal #561 .

We expect nominal types to support a number of features: methods, interface implementations, next pointers, etc. The anonymous type syntax is instead designed to only support data fields (with possible defaults) so they can be very concise and declared inline in contexts like a return type. The question is, is it better to use the same introducer to emphasize "these are all examples of record types and I don't want to say 'or' all the time when talking about them" or better to use different introducers so that the different syntax is less surprising?

As a concrete example, here is what we are currently looking at anonymous types like this:

fn GetPoint() -> struct {.x: Int, .y: Int};

and nominal types like:

struct Point {
  var x: Int;
  var y: Int;
}
fn GetPoint() -> Point;

where the compiler knows which to syntax to use based on whether the word struct is followed by an identifier or an {.

Note that there is some interaction with question-for-leads issue #651 , but I've tried to frame this as an independent question.

[zygoloid]

Per #651 (comment), I think that using a different name ("struct" vs "class") for simple anonymous structure types versus for full-fledged named structure types would be useful, though that doesn't directly answer the syntactic question of what introducer to use.

#561 mentions that we could do without an introducer for anonymous struct types, and I think this is an option we should consider a bit more. I think this could be OK:

• {} is both an empty struct literal and an empty struct type, just like ()
• {.a: b} is a type
• {.a = b} is a struct literal
• {.a: b = c} is a type (with a default value for field .a)

This would be problematic if we wanted to also use the same syntax {.a: b = c} as a way of writing a struct literal with an explicitly specified type for the field .a, but that doesn't seem to be part of the structs proposal for now at least. (I think we could still make that work if we wanted, by saying that you can use such a value as either a struct literal or as a struct type, sort-of mirroring how (Int) can be used as either a tuple value or as a tuple type, but that might be surprising in practice.)

I would prefer either a struct introducer or no introducer over a class introducer; I'd like to see more analysis of the no-introducer option before forming an opinion on whether I'd prefer a struct or no introducer.

[chandlerc]

This would be problematic if we wanted to also use the same syntax {.a: b = c} as a way of writing a struct literal with an explicitly specified type for the field .a, but that doesn't seem to be part of the structs proposal for now at least.

I wouldn't find the syntax {.a: b = c} desirable for achieving that effect though... I think we already have syntax for that construct which I prefer: {.a = c as b}

[josh11b]

Based on discussions yesterday, I think I heard that we were converging on ​the "no introducer" for anonymous struct types approach described in @zygoloid 's last comment.

• This creates a consistency: introducers are used when introducing new names, this doesn't introduce a new name so it doesn't have an introducer.
• It avoids having a different introducer for things that are still treated as classes for many purposes.
• We don't think the parsing difficulties will be too bad.
• We do want to use these type expressions in contexts that will benefit from being more concise.
• It is consistent with our approach to tuples and tuple types.

For both this and tuples, we are taking a risky approach as an experiment with the understanding that it may not work out, but if it does, we are happier.

[zygoloid]

Decision: As per @josh11b's most recent comment: structural data class types ("struct types" for short) have no introducer. {.x: T, .y: U} is a struct type, and {.x = 5, .y = 7} is a struct value. Just like () (and ((), ()), etc), {} is both a value and the type of that value (and by extension, so are ((), {}) etc).

There is a risk of future parsing problems here: we will want to avoid the syntax of a field initializer from ever overlapping with the syntax of a field declaration. But that doesn't seem like a significant problem given the information we currently have.

[Edit 2021-08-06: changed struct type syntax from {x: T, y: U} to {.x: T, .y: U}.]