Chandler Carruth

Looking at option (1), it is very close to the status-quo in Carbon. It is also very much the approach of C++ currently. So in some ways, this is the...

Looking at (2): One observation is that there is another direction that may seem distinct but I think is usefully included in (2), let's call it (2b): Only *types* are...

Looking at (3): Richard and I talked pretty extensively about this option. Specifically, we explored what it would look like to *deeply* embrace this direction and try to get something...

Lot's of fresh discussion from today's open discussion session, decent notes (huge thanks to all!!) here: https://docs.google.com/document/d/1gnJBTfY81fZYvI_QXjwKk1uQHYBNHGqRLI2BS_cYYNQ/edit?resourcekey=0-ql1Q1WvTcDvhycf8LbA9DQ#heading=h.x7xa7wz11td3 I'll try to provide my summarized take-aways here, happy for others to add...

Closing explorer-specific issues as not-planned for now due to our decision to prioritize working on the toolchain over other implementation work in the near term: https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p3532.md

My initial thoughts -- I'd be happy to generalize the rule we have for inheritance in #2355 for other cases of a class extending something and explicitly declaring a name...

Closing explorer-specific issues as not-planned for now due to our decision to prioritize working on the toolchain over other implementation work in the near term: https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p3532.md

It seems like we're experimenting effectively with `let X:! auto = Y` being referentially transparent as @josh11b described. It isn't clear we need to make a more firm decision on...

Talked with @josh11b about this, and it doesn't seem urgent to really settle/decide this. There is a rough approach in the current design and the best way to make more...

> Discussing with @zygoloid , the `let T:! Foo = Bar;` shouldn't add the `where .Self == Bar` clause, but instead should do a `observe T == Bar;` Would be...