Skip to content

Rename tuple structs to something else #7288

Closed

Description

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

Activity

  1. mstewartgallus commented on Jun 22, 2013

    @mstewartgallus
    Contributor

    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.

  2. emberian commented on Jun 22, 2013

    @emberian
    ContributorAuthor

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

  3. glaebhoerl commented on Jun 22, 2013

    @glaebhoerl
    Contributor

    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.

  4. emberian commented on Jun 22, 2013

    @emberian
    ContributorAuthor

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

  5. mstewartgallus commented on Jun 22, 2013

    @mstewartgallus
    Contributor

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

  6. emberian commented on Jun 22, 2013

    @emberian
    ContributorAuthor

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

  7. glaebhoerl commented on Jun 22, 2013

    @glaebhoerl
    Contributor

    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.

  8. emberian commented on Jun 22, 2013

    @emberian
    ContributorAuthor

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

  9. mstewartgallus commented on Jun 23, 2013

    @mstewartgallus
    Contributor

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

  10. catamorphism commented on Sep 27, 2013

    @catamorphism
    Contributor

    Closing due to lack of consensus.

  11. added a commit that references this issue on Jun 17, 2021
  12. added a commit that references this issue on Aug 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-grammarArea: The grammar of RustE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions