You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"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.
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.
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.
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.
@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.
@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.
@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.
Activity
mstewartgallus commentedon Jun 22, 2013
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 commentedon Jun 22, 2013
@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 commentedon Jun 22, 2013
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
newtypeuse case (see below). It's nice all around.(One way you could simplify it is by collapsing
structandenum, but C/C++ programmers wouldn't like that, and even as just syntax sugarstruct Foo { ... }instead ofenum 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.
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 commentedon Jun 22, 2013
@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.
mstewartgallus commentedon Jun 22, 2013
@cmr By single case enum I meant anything like
enum Single { Single(int, int) }. I think havingenum Single(int, int)be syntactic sugar for that would be really sensible.emberian commentedon Jun 22, 2013
@sstewartgallus I'd be ok with that. I think it's better than using
structfor that purpose.glaebhoerl commentedon Jun 22, 2013
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
structkeyword.emberian commentedon Jun 22, 2013
@glehel the more I think about it (your examples were particularly enlightening), the more I think
structis 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.
mstewartgallus commentedon Jun 23, 2013
@glehel I feel that cases 6, 2, and 3 are not useful, and that the fifth case is useful.
catamorphism commentedon Sep 27, 2013
Closing due to lack of consensus.
Auto merge of rust-lang#7288 - camsteffen:use-self2, r=phansch
Merge rust-lang#7288