Erik Ernst
Erik Ernst
@sigmundch wrote: > could instead be based on some static structural typing I agree with @Levi-Lesches that the connection to an explicitly declared type is good for correctness and for...
The current views proposal uses `implements T1, .. Tk` to indicate that the members are implemented by a view, and the signatures are correctly overriding the signatures in `T1, .....
@sigmundch, I made an attempt to develop the ideas about allowing for-in statements to work on an object which has an `Iterable`-ish view on it in https://github.com/dart-lang/language/issues/2150, with the two...
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 an...
I think the underlying conflict here is (1) `toString()` is a low-level mechanism which is mostly suitable for debugging and in quick-and-dirty programming to solve an immediate problem; hence, (2)...
I tend to prefer @munificent's first proposal (using names like `field0` .. `fieldN` for the positional components, although we might of course use a different specific name than `field...`). There...
I don't see any new issues in relying on assignability. For example, we maintain that `o.whatever()` checks for the existence of a member named `whatever` at run time, and there...
I think the core issue here is the conceptual clash: When we're matching an object `o` with a pattern `p`, and the static type of the expression that yielded `o`...
As an aside, @munificent wrote: > lists are slightly weird I think we'll have to get some data on this. The obvious choices are the following: ```dart var list =...