Bob Nystrom

I like all three levels you have here and I think the minor language changes required to enable them are worth doing. At some point, I think we should consider...

Yes, like that. I don't know if I am sold on committing to stable getters—to being able to define *non-fields* that are promotable—but at least being able to control which...

> > ... but at least being able to control which fields are seems worth doing to me. > > I think all of them are stable (do you know...

> > If we implicitly allow any public final field to promote, then it means changing that field to a getter is a breaking API change. I > > When...

That sounded familiar, but it took me a while to dig it up. Yes, I did a *very* rudimentary bit of digging. Here's the old email: I went through all...

Yeah, I don't see any reason to disallow const records. I'll leave this open as a reminder to update the proposal to include it.

> The _structure_ of a record or a record type is the number of positional elements and the set of named element names, written as a pair (_n_, _S_) ∈ ...

We discussed this in the language meeting today. We'd like some way to wait multiple futures in parallel that preserves the type of each future (which `Future.wait()` doesn't do). We...

> * If more than one future throws, the result should throw. What should it throw? > * If some futures complete and others throw, the successful values should be...

> The only real problem with using library methods/extensions is that it doesn't scale infinitely. In practice, I think that won't be a problem. The only reason to prefer awaiting...