josh11b

> Regarding argument labels, as I commented on #339, it's not clear to me why they should be provided. I don't understand why developers shouldn't be expected to rename their...

I'm going to remove the function declaration syntax from this issue, since that is more complicated.

I've also removed the destructuring, since that should ideally use the same pattern syntax as function declarations.

An argument against using the dot/designator syntax "A" is that `.a` really looks like it should be "the `a` field of a struct that we are going to figure out...

I've been having some conversations about this recently, and with the recent resolution of https://github.com/carbon-language/carbon-lang/issues/542 I think we are in a better position to answer this question. What I've been...

Please let us know your opinion! Vote here: https://discord.com/channels/655572317891461132/709488742942900284/846932433832378410

The overview does described unformed state, see https://github.com/carbon-language/carbon-lang/tree/trunk/docs/design#unformed-state , but the [classes design document](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/classes.md) still needs to be updated.

We've been saying one of the important things about final classes is that you can add names to them without evolution concerns. We could accomplish that by saying `adapter X...

Alternatively, we can add names in an extending adapter without evolution concerns if names in the adapter shadow those in the final class.

Of the possible rights reserved for `final` classes, my opinion is: - The implementation of `virtual` methods should be fixed. This supports the performance goal by avoiding virtual dispatch. -...