Bob Nystrom

Yeah, I'm with you. The syntactic cost to move some values into the fields of a class in Dart is too damn high. However, I don't know if moving to...

> ```dart > class Foo { > Foo({ this.* }); > final int bar; > final int baz; > } > ``` > > ...or some such, where this.* (or...

I think this is a good idea. It definitely feels weird. If I had a time machine, I would sure as heck get rid of `_` for privacy because it...

> Has anything been decided here ? No decision yet. The language team is mostly focused on views, records, pattern matching, and macros, so other smaller language changes aren't getting...

My feeling has always been that if you need separators in your number literal, you have likely already done something wrong. Instead of separators, create a const expression that shows...

> It is not always possible to decompose a number into its composite parts. I think one of these is usually true: 1. The number can be decomposed into smaller...

No updates, sorry. We are hard at work on null safety, which I hope everyone agrees is higher impact that digit separators. :)

> We'd want to avoid switch case expressions whose type implies that there could never be a match, that is, we should probably change the rule such that it is...

The original issue discussing this is #175. I agree that it's very annoying to have `null` sneak into a user-facing string through string interpolation. But at the same time, it...

I would like to come up with a positional field accessor expression syntax, yes. I don't have a design yet and I don't think it's *essential* so the current proposal...