Lasse R.H. Nielsen

My proposal: Allow the `[]` operator to be used on expressions of a tuple type. The argument must be a *literal* (possibly just a *constant*, but I'm not sure even...

(For the record, I have always wanted you to use `operator ()` or `operator call` instead of just `call` to make an object callable.)

For LUB, I'd go with `LUB(t1, t2)` where `t1` and `t2` are tuple types as: * If `t1` and `t2` have the same *structure* (same number of positionals, same names)...

@tatumizer It's one way of thinking, but it requires `(int, int, {int foo, int bar})` to be a subtype of `(int, {int foo})`. Subtyping means assignability. (Or at least it...

The `String.+` was actually removed, not for performance, but to avoid a Java puzzler. At that point it took `Object` as argument and did `.toString()` on it, like in Java...

The Java puzzler was probably based on real issues for Java programmers. That was a long time ago, and I'm not sure anyone doing manual formatting would put the `2...

I do have some problems reading the pattern `foo?` as meaning bind `foo` if the value is *not* `null`. If anything, it looks like it matches the previous pattern *or*...

I think we still need to fix the cases prior to "implements `Future`, because `T` is `FutureOr` is not true for a type variable `X` with bound `FutureOr`, and "is...

About `Object`, we *can* have **flatten**(`Object`) be `Object` if the runtime behavior is only to await a `Future`, not a `Future`. That is what we do for a static type...

@eernstg > But `await e` should await any future, and it's up to the static type of the expression to faithfully allow for any outcome that this could produce. That's...