Leaf Petersen

In general, allowing this concerns me less than the question of overriding things from interfaces (discussed in #2360), since we only allow extending other extension structs, and there should be...

> Maybe this should be called "shadowing" instead of "overriding"? @ds84182 I would like to have some verbiage to distinguish between arbitrary shadowing (e.g. replacing a method returning an `int`...

> Perhaps this is excessively verbose. It might also be noisy, as the value may never have been used with `DerivedInteger` anyways, so the confusion could never arise. I don't...

@rileyporter > For example, returning a `List` instead of the DOM type `NodeList` (something we thought we might be able to do with having views extend other views) would have...

@rileyporter > For example, returning a `List` instead of the DOM type `NodeList` (something we thought we might be able to do with having views extend other views) would have...

Thanks for taking it offline and cleaning up. I realize feelings run high on some of the issues we discuss, but we really need to keep the discussions here technical...

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

> Why not have `toString()` implement this behavior instead of adding an additional `toDebugString()`? Because overriding `toString` to provide debugging information is a common cause of code bloat in large...

> I think we should consider splitting this into its own feature, I suggest to look at this as an _interface auto derivation_ feature which works for structs and classes...

> Is it the AUTHOR of the Bad class, or the USER of said class? Sure, user will benefit, too, if the author makes fewer mistakes, but other than that?...