Sdk: introduce struct (lightweight class)

[DartBot]

_This issue was originally filed by @tatumizer_

---

Please consider introducing struct (as lightweight class)
Example:
struct ABC { int a; String b; DateTime c; }

should be compiled into

class ABC {
  int a;
  String b;
  DateTime c;
  ABC(this.a, this.b, this.c){}
}

[madsager]

_Added Area-Language, Triaged labels._

[lrhn]

Depending on the order of the fields seems a little "un-dartlike" for me.
I'd prefer at least getting a constructor using named arguments:
  ABC({this.a, this.b, this.c});

Then you can do
  new ABC(a: something, b: other, c: whatnot)
which explains exactly what object you are creating.
Not much shorter than
  new ABC()..a = something..b = other..c = whatnot
though.

[DartBot]

_This comment was originally written by @tatumizer_

---

ABC({this.a, this.b, this.c});
I agree with that.
The argument for struct becomes stronger if we consider struct as a value object, and automatically define toString(), hashCode, ==, compareTo and maybe something else based on values. Then it will be good not only for returning "tuples", but for constructing composite keys. [Sorting by composite key is very common in web applications; defining hashCode and others manually is quite error-prone and boring]

[DartBot]

_This comment was originally written by @tatumizer_

---

I want to document Lasse's suggestion from mailing list.
Quote:
Maybe make the fields be specified as arguments instead of as fields:
  class Person(String name, int age);
This makes all parameters implicit fields, instead of making all fields implicit constructor parameters.
Then you can specify them as optional or named as well:
  class Person(String name, {int age = 0});
It's just a shorthand for creating a class of (final?) fields and a constructor with the specified initializing parameters.
/End Quote

I think it's a beautiful idea. We follow the syntactic pattern of typedef for function here, instead of inventing new syntax.
Still not sure, maybe "struct" would be a better word in this context (instead of "class") - because this might be a variant of class with a number of autogenerated methods, so we need a general name for this thing, which is not simply "class".
(Issue for discussion).

[gbracha]

The appetite for syntactic sugar is unbounded, but it comes at a real cost. Every reader of the language, both human and mechanical, has to deal with all this extra stuff. Everyone who learns the language needs to learn each extra construct, and the manuals get bigger and bigger. The tools acquire feature upon feature and grow bloated. It's also a barrier to new tools.

All of this is by way of explaining why keeping the language relatively small is much better than accommodating every potential feature.

In this case, introducing a new construct so that one can avoid typing a constructor is in my judgement the wrong thing to do. It also has an opportunity cost; the cycles spent dealing with these issues come at the expense of dealing with more productive features, or improvements to existing ones. Nothing is free.

---

_Set owner to @gbracha._
_Added WontFix label._

[DartBot]

_This comment was originally written by @tatumizer_

---

I agree with that. The game is not worth the candle.
Main advantage of struct could be: easy serialization, but it can be achieved through other means (e.g. along the lines of minimal_serialization package by Alan).
However, by the same token, yield* is even "more unnecessary" than struct IMO ("Iterable.traverse" method can do the same) :-)
(I have doubts even about plain yield, I think your logic (small is better) applies here, too).

[gbracha]

I agree that sync* methods are of debatable value. They're there mainly for symmetry, and on the grounds that once you implement all the CPS like machinery for async, they don't add that much cost. But it is a judgement call.

[SAGARSURI]

Is there something similar to inline classes in Dart?

[eernstg]

Cf. https://github.com/dart-lang/sdk/issues/33295#issuecomment-636792957.