Leaf Petersen

> > That is, I think it is arguably really sketchy as a language design that you can have a literal pattern which matches something which is in all shapes...

cc cc @mit-mit @lrhn @eernstg @chloestefantsova @johnniwinther @munificent @stereotype441 @natebosch @jakemac53 @rakudrama @srujzs @sigmundch @rileyporter @mraleph @mkustermann

> My simple question is why are those two separate feature sets discussed in the same issue/ proposal? I (and others) have concerns about the growing surface area of the...

Yeah, pattern matching is a problem (though I wonder whether we should have a `...` pattern for records). For the types, you can always define a typedef.

> It is not allowed to start named parameters with an underscore. The names of positional parameters should not be meaningful. Huh, I guess when we've discusses this it's been...

> Yeah, I had a TODO in the proposal for that. Lasse suggested not doing it because it may require us to keep around more reflective information for records than...

cc @mit-mit @lrhn @eernstg @chloestefantsova @johnniwinther @munificent @stereotype441 @natebosch @jakemac53 @rakudrama @srujzs @sigmundch @rileyporter @mraleph

I'll admit that the `data class` and `view class` variant of the syntax is growing on me.

@lrhn > The value might be _assignable_ to the interface type, and it might forward interface methods to the underlying object, but there is no relation between the members declared...

> But when the view has an `implements` clause, the corresponding boxing class has the same `implements` clause, with completely normal semantics. Yes, I was being brief. In this proposal,...