Chandler Carruth

My main thought is that I agree, this isn't really a FAQ answer any more. And we *do* have documents that detail the things you're calling out as needed, even...

@josh11b and @mconst and I talked a whole bunch about this. I was really not seeing options that I was happy with or that felt satisfying. My inclination was to...

> > This doesn't change the semantics of the R-values themselves though -- they still are allowed make copies if legal and useful. Otherwise they behave exactly as a const...

> Just getting my head around this; in your examples, what is the default behaviour where no initialization specifier(?) is present: > > ``` > // ✅ - we can...

At the time, C++20 was still very incomplete in the released compiler we were using. If there is a good motivation, we can consider switching.

I think there is a lot of confusion here. The issue, in the title, is about the *implementation* of Carbon's tools. Our *interoperability* and *migration* goals are completely separate from...

Another factor here is that we say in our [goals](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#performance-critical-software:~:text=Code%20should%20perform%20predictably.): > Code should perform predictably. Having an implementation-dependent order of fields will create significant variability in performance. And perhaps even...

FWIW, I agree with what @josh11b has written here: > Carbon has a goal of being easy to parse for tooling, which has meant that we have considered and rejected...

I'm generally very positive about string interpolation or f-strings etc. However, I don't think this is a meaningful issue for leads at this point? We would need a proposal to...

> In Carbon, `0x1A` is valid but `0x1a` is not. Unlike C/C++, hex digits are case sensitive. > > In Wuffs, both are valid (from the compiler's point of view)...