Proposal: Name annotation for tuple types

[hez2010]

Background

Here're ways to access tuple element in Rust for now:

let x: (i32, f64, u8) = (500, 6.4, 1);

// first
let (a, b, c) = x;
println!("{} {} {}", a, b, c);

// second
println!("{} {} {}", x.0, x.1, x.2);

The first approach is a deconstruct process, which deconstruct the tuple x into a, b and c.
The second approach is to access elements in the tuple x directly.

However, when we use a tuple, it's hard to know meaning of its elements without comments or documents, and things like .0 are hard to distinguish if you lack acknowledge of a tuple.

Proposal

I proposed name annotation for tuple types:

let x: (count: i32, price: f64, type: u8) = (500, 6.4, 1);

And then we can access elements in the tuple x in this way:

println!("{} {} {}", x.count, x.price, x.type);

It's more intuitive and convenient.
Note that count, price and type are just name annotations for the tuple type, and they don't change the actual type (i32, f64, u8). x.count will be compiled to x.0.

Name resolving

Names are resolved as ways they're declared.

fn bar(v: (a: i32, b: bool)) -> (x: i32, y: bool) {
  v.a // ok
  v.b //ok
  v.u // error, v wasn't declared u
  v.v // error, v wasn't declared v
  return v;
}

fn main() {
  let tup: (u: i32, v: bool) = (5, false);
  let mut result = bar(tup);
  result.x // ok
  result.y // ok
  result.a // error, result wasn't declared a
  result.b // error, result wasn't declared b
  result.u // error, result wasn't declared u
  result.v // error, result wasn't declared v
  result = tup;
  result.x // ok
  result.y // ok
  result.u // error, result wasn't declared u
  result.v // error, result wasn't declared v
}

[SimonSapin]

Is this the same as structural records? #2584

[hez2010]

@SimonSapin I don't think they're same.
You need to declare a record explicitly and then you can use it as "tuple with named fields", whereas tuple is more like an ad-hoc solution for "anonymous records".
I think the ability of "named fields" is also needed for tuple types.

(a: i32, b: f64), (x: i32, y: f64) and (i32, f64) are same with each other, they all have type (i32, f64), and they can have fields with different names in different contexts.

[SimonSapin]

Yes, structural records are anonymous. They’re not structs.

The difference seems to be that in your proposal, positions/ordering are still meaningful?

(a: i32, b: f64), (x: i32, y: f64) and (i32, f64) are same with each other,

Does this mean that the (a: i32, b: f64) and (b: i32, a: f64) types are also the same? Then how is the something.a expression resolved?

[hez2010]

@SimonSapin
It depends. For example:

fn test1() -> (a: i32, b: f64) {
  ...
}

fn test2() -> (b: i32, a: f64) {
  ...
}

fn main() {
  let x = test1();
  let y = test2();
}

In main(), x.a is i32, x.b is f64, y.a is f64 and y.b is i32

[SimonSapin]

This implies that x and y do not have the same type, right? So this wouldn’t be allowed:

fn main() {
  let mut x = test1();
  x = test2();
}

In that case I don’t understand what you meant by:

(a: i32, b: f64), (x: i32, y: f64) and (i32, f64) are same with each other

[CryZe]

I believe the labels are merely syntactic sugar here and are not part of the type system.

[hez2010]

I believe the labels are merely syntactic sugar here and are not part of the type system.

Yes. It requires no change to existing type system and it just a sugar for compiler and code analysis.

[CryZe]

It breaks down on reassignment with conflicting labels though. What do you envision happens then?

let mut foo = (a: 5, b: true);
foo = (x: 7, y: false);

foo.a // ????

[hez2010]

@SimonSapin

In that case I don’t understand what you meant by:

(a: i32, b: f64), (x: i32, y: f64) and (i32, f64) are same with each other

It means the type of (a: i32, b: f64), (x: i32, y: f64) and (i32, f64) are same, they're all (i32, f64) type but with different field name alias.

If they're different types, assigning a (x: i32, y: f64) to a (a: i32, b: f64) variable will failed.

[hez2010]

@CryZe

It breaks down on reassignment with conflicting labels though. What do you envision happens then?

let mut foo = (a: 5, b: true);
foo = (x: 7, y: false);

foo.a // ????

What if we don't allow the syntax let x = (a: 5, b: 1.3), but only allow let x: (x: i32, b:f64) = (5, 1.3)?
Then it will make sense, since you cannot specify name labels on values but only on the type signatures.

I've modified my original proposal.

[CryZe]

I believe this still breaks down on reassignment:

fn bar() -> (a: i32, b: bool) { ... }
fn baz() -> (x: i32, y: bool) { ... }

let mut foo = bar();
foo = baz();

foo.a // ????

Unless you can't specify types like this in function return types? That would start to become very inconsistent (also much less useful than structural records).

[SimonSapin]

they're all (i32, f64) type but with different field name alias.

This is a contradiction to me. Where else would the names exist but as part of the type?

[hez2010]

I believe this still breaks down on reassignment:

I think it'd better fix its name labels to the first assignment, this behavior is also used in C# ValueTuple<>.

fn bar() -> (a: i32, b: bool) { ... }
fn baz() -> (x: i32, y: bool) { ... }

let mut foo = bar();
foo = baz();

foo.a // foo.a is i32
foo.b // foo.b is bool
foo.x // compile error
foo.y // compile error

[hez2010]

@SimonSapin @CryZe

This is a contradiction to me. Where else would the names exist but as part of the type?

The names of a field in tuple aren't part of a type, they are only language sugar for better code readability and understanding. It can be achieved completely by compiler and code analyzer without any change to existing type system.

Here is a full example:

fn bar(v: (a: i32, b: bool)) -> (x: i32, y: bool) {
  v.a // ok
  v.b //ok
  v.u // error
  v.v // error
  return v;
}

fn main() {
  let tup: (u: i32, v: bool) = (5, false);
  let mut result = bar(tup);
  result.x // ok
  result.y // ok
  result.a // error
  result.b // error
  result.u // error
  result.v // error
  result = tup;
  result.x // ok
  result.y // ok
  result.u // error
  result.v // error
}

[Ixrec]

That the labels get returned from one function to another like that seems equivalent to "the labels are part of the type" to me. They're still metadata about bar that the compiler needs to know about when compiling main(), and if we replaced bar with an argument of function type, then we could only allow it to have function values that returned the same labels or else it'd be impossible to know what result.x is supposed to compile to.

What I see in this snippet is not an absence of label typing, but implicit coercions between named tuple types that differ only in their names. That raises questions like "does (a: i32, b: bool) coerce to (b: bool, a: i32)? To (y: bool, x: i32)?" and "Does coercion only happen at function returns? It can't be everywhere, or else result.x would likely end up magically accessing result.a or something." Regardless of what precisely a "type" is, those still need answering (and I suspect any complete answer is complex/subtle enough to make the feature not worthwhile).