Rename tuple structs to something else

[emberian]

"tuple struct" is a pretty terrible name. I propose "named tuple". This would also change the syntax from

struct Foo(....)

to

tuple Foo(...).

Only reason is because you can't have impls or traits on typedefs. If you could, this feature could be reduced to type Foo = (....), which would be ideal I think.

[basic-calculus]

I'm strongly opposed to adding a tuple keyword. I think that an alternative might be to use the enum keyword instead. I feel that it would be very sensible to have what is now a tuple struct be a single case enum.

[emberian]

@sstewartgallus what is a single case enum?

Tuple structs are like struct Foo(uint, int, Bar). They actually do share a lot of the enum code though (which is why I'm looking into them: the IR they generate is awful).

I agree that adding a keyword is bad but there are no suitable ones already in the grammar... and the current situation is pretty inexplicable.

Most of the badness comes from abusing the term struct. A tuple struct is not a struct like any C/C++ programmer would expect.

Maybe it's just something we'll have to live with, though.

[glaebhoerl]

I might be the only one, but I really like the current system, and can't think of any way I would improve on it. Data can use either named syntax (record-like) or unnamed syntax (tuple-like). Structs are single-variant, enums can have multiple. Built-in tuples use the unnamed syntax and also leave off the type name. Structs using tuple-like syntax with a single field just happen to be perfect for the newtype use case (see below). It's nice all around.

(One way you could simplify it is by collapsing struct and enum, but C/C++ programmers wouldn't like that, and even as just syntax sugar struct Foo { ... } instead of enum Foo { Foo { ... } } is nice.)

All of that said, as the way to talk about them I'm not attached to "tuple struct" even a little bit, and "named tuple" doesn't sound any worse.

Only reason is because you can't have impls or traits on typedefs. If you could, this feature could be reduced to type Foo = (....), which would be ideal I think.

The point isn't to give it a new name, it's to give it a new type, so that the compiler yells at you if you mix them up. struct Foo(Bar) as a lightweight syntax for doing that is as good as any I've seen.

[emberian]

@glehel I like the current system too. "tuple struct" is the only thing that annoys me. I might be the only one, though.

As for newtype, I thought typedefs did that, but I guess not, doing some tests. Nor would it make sense, really. Typedefs are most often used to have a shorter name for something, which wouldn't work if it were a newtype.

[basic-calculus]

@cmr By single case enum I meant anything like enum Single { Single(int, int) }. I think having enum Single(int, int) be syntactic sugar for that would be really sensible.

[emberian]

@sstewartgallus I'd be ok with that. I think it's better than using struct for that purpose.

[glaebhoerl]

FWIW that's very similar to the old syntax: enum Foo = T (#3534).

You can currently write four things:

(1) struct Foo { a: T, b: U, ... }
(2) struct Foo(T, U, ...)
(3) enum Foo { Foo { a: T, b: U, ...}, ... }
(4) enum Foo { Foo(T, U, ...), ... }

These have a certain logic to them: 2 * 2 = 4 possibilities.

You're proposing a fifth:

(5) enum Foo(T, U, ...)

Which of the existing four would you remove? Presumably (2); also (4)? (1)? Would you also add:

(6) enum Foo { a: T, y: U, ... }

which follows from the same syntactic-sugar-for-single-case-enums logic? At that point there's no reason to keep the struct keyword.

[emberian]

@glehel the more I think about it (your examples were particularly enlightening), the more I think struct is fine syntax.

My biggest beef is the name. The only other thing I can really come up with, though, is unstructured struct, which is longer and also rates fairly high on the WTF scale.

Maybe there isn't a better name.

[basic-calculus]

@glehel I feel that cases 6, 2, and 3 are not useful, and that the fifth case is useful.

[catamorphism]

Closing due to lack of consensus.