Tuple structs aren't used often, but the whole point of them is to force you to name a type. The idea is to restrict the types that you can call a function with; it turns a given tuple from a structural type to a nominal type.

For example, say you have two functions, where each function takes a single tuple of two floating point numbers:

  // Converts a Cartesian coordinate to a polar coordinate
  fn to_polar(coord: (f64, f64)) -> (f64, f64) { ... }

  // Calculates the area of a rectangle
  fn area(rect: (f64, f64)) -> f64 { ... }

Now, if you have a tuple that represents a coordinate, perhaps you don't want to feed it to the `area` function. Likewise for feeding a rectangle to the `to_polar` function. But because tuples are just structural types, something like `area(to_polar((2.5, 3.7))` is completely legal.

If you didn't want to allow this, or even if you just wanted to have greater control over all these anonymous tuples floating around, you'd use tuple structs to give them names:

  struct CarteCoord(f64, f64);
  struct PolarCoord(f64, f64);
  struct Rectangle(f64, f64);
  struct Area(f64);  // bonus round!

  fn to_polar(coord: CarteCoord) -> PolarCoord { ... }
  fn area(rect: Rectangle) -> Area { ... }

Taking the above steps makes `area(to_polar(CarteCoord(2.5, 3.7)))` a compile-time error. It's all about how strict you want to be with your types.

Sure, and all of that makes sense for function arguments, but for a destructuring assignment I'm not sure the same constraints are meaningful.