Chandler Carruth

FWIW, this style was something that I think at least a few of us have thought about at various points. To expand a bit on what @jonmeow said about why...

I think there is some confusion here... As mentioned in #1436 -- whatever build system we use internally to build Carbon tools and components has no effect on what build...

Regarding comment https://github.com/carbon-language/carbon-lang/issues/1519#issuecomment-1192996778 -- again, I think we're pulling the question from #1544 into here and should avoid that. Build system *support* is a complex topic that is best discussed...

> [https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/README.md#imports](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/README.md?rgh-link-date=2022-07-20T12%3A11%3A24Z#imports) says "The `import library ...` syntax adds all the public top-level names within the given library to the top-level scope of the current file as private names". IIUC...

> ``` > import Cpp library "a.h"; > import Cpp library "b.h"; > > var f: Cpp.Foo; // which import line gave me `Cpp.Foo`? I can't tell. This looks like...

> I'm still not sure if I understand the Carbon package vs library distinction correctly, but my rough model (based on Go experience) is that Carbon package ~ Go module...

> By "external header file", do you mean: > > * a file designed for external consumption: this is the .h file that users (as opposed to the people developing...

We can still generate RR diagrams for the LR(1) grammar? Is this issue still useful?

Our contribution tools are documented in our [contribution tools](/docs/project/contribution_tools.md). Generally we try to be pretty open ended on thing like editors / IDEs though. Does this help?

> Thanks again for reply ! Well as you've described it's different from C++ and maybe I will not be the only one to be confused with this, I can...