Proposal for Goals

[jonmeow]

Co-authored with chandlerc

• Draft doc
• RFC topic
• Decision request
• Decision announcement

[hfinkel]

Some comments inline...

[hfinkel]

There area subtlety that might be worth acknowledging here. To what extent does disallowing "bad" code patterns overlap with semantic restrictions designed to enable optimization or enable tooling to detect errors?

[jonmeow]

How about rephrasing this as "The language should stay out of the business of legislating bad code patterns except where it affects detecting logic or performance errors."?

@chandlerc (FYI)

[chandlerc]

Hmm, I lik ethe direction here, but I think it might require a bit more of a change. Fundamentally, I think the thing Hal is pointing out that erroneous patterns should still be in-scope to restrict. This section is talking about "bad" things that in some way aren't fundamentally errors, and that's the subtlety that I think Hal is driving at here?

[jonmeow]

Just noting: I'm not clear what kind of different wording you might be suggesting. It's been adjusted a little, and if you still have concerns, explicit suggestions may help.

[chandlerc]

I'll suggest an update to this section that I think gets more deeply at the issue raised by Hal here.

[hfinkel]

I'm concerned that this goal seems at odds with the goals related to bounded-look-ahead parsing and simple name-lookup rules (which are very important goals). How would we migrate templates that "work" because of ADL or other aspects of C++ name-lookup rules? Do we have some idea that this is a very-small percentage of the overall code of interest? Is it not idiomatic?

[jonmeow]

There's an aspect here that gets to the prioritization of language goals. Higher priorities may preempt if there are conflicts, or we may find more complex workarounds to make migration work, especially where it does not impact code outside of migration/interop code.

For the case of name lookups, I can imagine migration tooling identifying which C++ APIs a caller is using and, as those APIs are translated to Carbon (or vice-versa), inserts extra wrapper code if default name-lookup would yield a different API being called.

i.e., translating some C++ behavior may result in more complex Carbon code in order to achieve the same logic, possibly leaving it for humans to improve style later if so desired.

We do expect some code won't be possible to migrate automatically, which is where the 2% comes in (albeit as a somewhat arbitrary threshold). Minimally, I'd hope we can get warnings if migrated code should be expected to behave differently, although we probably won't be able to catch every case.

[chandlerc]

FWIW, my stance is that code that happens to work via ADL is very likely non-idiomatic.

But I think there may also be some fallback translation options here, perhaps at a loss of readability.

I do agree that the ranking starts to show a bit of its importance here -- we shouldn't be complicating the name lookup rules just to make the automated translation somewhat cleaner unless this is a massive practical problem... Which I think is unlikely, but I suppose possible. I would at least want to have very clear evidence to support taking on the cost of more complexity in name lookup or similar.

[hfinkel]

We say something here about GPUs, but we don't really say anything about parallelism in general.Talking about the ability to express parallelism, semantically, is perhaps even more important than GPUs in particular. We should aim to allow the expression, semantically, of computational patterns that naturally map onto common accelerator hardware. Then we'll need to decide how to express data movement and locality - work scheduling and placement.

[jonmeow]

I agree parallelism should be addressed in some way, although I think the "Code should perform predictably" paragraph above may partly address your concern without addressing common accelerator hardware directly.

What about something like "Common yet complex tasks, e.g., parallel code, should be well-supported in ways that are easy to reason about.", under "Code that is easy to read, understand, and write"? (see changes) Do you have suggestions for other ways to phrase this? I do wonder if that section got a little too abstract in its phrasing.

@chandlerc (FYI)

[chandlerc]

I lean a bit more toward Hal's phrasing, but I'm not sure where to embed that within the document.

Does it make sense to try to add thsi clarity in a follow-up, or to do it here? If here, I'll try to think more precisely to make a constructive suggestion of where it might fit best.

[geoffromer]

I'd rather not call out specific software structures, because it seems like a slippery slope (e.g. why only parallelism, and not concurrency or asynchrony?). In any event, doesn't the goal of supporting performance-critical software imply support for parallelism?

[chandlerc]

The performance section doesn't really talk about hardware, and in large part because that's largely covered here.

I'd lean towards calling out the specific software structures that are necessary to program modern, major hardware. This, for example, would differ significantly from language that relies on compilation techniques to translate one programming model into another. Instead, I think this goal needs to anchor Carbon into fairly direct support for the necessary set of programming models to directly target the relevant hardware.

[jonmeow]

Spoke with Chandler about this, added paragraph mentioning SIMD (may be easiest to comment on the latest revision, may iterate too)

[chandlerc]

I'm really happy with the current state I think going into a decision. My comments and suggestions below are mostly minor. I've also tried to go back and resolve everything that I seemed to be in the critical path of resolving.

For what it's worth, I plan to affirm with a rationale that having the explicit exposition of our goals, how we make tradeoffs between them within the language design, and some indications of success will be necessary for the project to remain cohesive and effective at charting out a viable future path for C++.

[chandlerc]

FWIW, I would agree with "Common Linux distributions" but I'm not sure that the distinction between that and "Linux", or the fact that "Android" is in some senses a Linux-derived OS, really matters much to most readers. I'd be happy either way there.

Actually, what about something more direct:

"Linux (including common distributions, Android, and ChromeOS)"?

In particular this would be nicer IMO as it gives a single entry for the family, similar to the Apple-based OSes.

[chandlerc]

I'd not say "Carbon will not support C++ exceptions". I think the interop and migration layer might have a story around exceptions. But I agree w/ the rest of this, maybe just focus there.

[josh11b]

Do we want to say anything about "reasonably fast by default" or "favors constructs that can be compiled to efficient code" or something like that? It was the sort of statement I just assumed was in the goals until I reread this section. The way this is written now, we could create a slow language as long as it was predictable and had an inline assembly escape hatch that was painful to use and hence rarely used.

[jonmeow]

TODO in #106

Note though, I don't think this is an issue right now due to "leave no room for a lower level language" -- inline ASM is still breaking the "rules and structure of Carbon". Arguably it may be unavoidable, but I think the implications should address most of your concern, could maybe just be more explicit.

[josh11b]

Suggested change

	> new tools has a higher cost than many people
	> appreciate."—[John Carmack](https://twitter.com/id_aa_carmack/status/989951283900514304)
	> new tools has a higher cost than many people appreciate."
	> —[John Carmack](https://twitter.com/id_aa_carmack/status/989951283900514304)

[jonmeow]

This is an emdash, so the current setup is appropriate per style. There's been a suggestion to change project style to deviate from the developer guide, but same as there, I'd rather handle style deviations separate from the proposal, to avoid ratholing on style.

[josh11b]

Okay, but I don't think that rule applies to naming the author for a block quote. This just looked like a mistake.

https://www.google.com/search?q=quote+with+author%27s+name&sxsrf=ALeKk02HsCsIppsFWE7tOk57yljr-HCghw:1594327431842&source=lnms&tbm=isch&sa=X&ved=2ahUKEwisvunBhMHqAhXPuZ4KHcMDCYYQ_AUoAXoECA4QAw&biw=1822&bih=1185

[josh11b]

Is this arguing for uniform & general language rules instead of trying to add exceptions and edge cases? Perhaps some of the argument is that usability includes making the language "simple" in the sense of "less to know to understand"?

[jonmeow]

I don't view the argument that way. I view it as more based in a concern that Carbon could identify "bad code" structures, and block them, to the loss of complex code that actually needs the structures for performance.

An example might be templates vs generics. We expect generics to be simpler. Rather than blocking use of templates in places we deem inappropriate, we should focus on encouraging use of generics. This is actually the opposite of arguing for simplicity, as the other structures exist and users implicitly need to know when to (or particularly not to) use them.

Simple code is better addressed by the next item, "clearly and simply specified"

[josh11b]

In general, I find this paragraph among the weakest in this whole document, and I struggle to make sense of what it is trying to say or how it would be applied.

[josh11b]

"... and the resulting performance more predictable"?

[jonmeow]

Adding as a TODO; #106

[josh11b]

Wording nit: tests are the thing that pass under sanitizers, not coverage

[jonmeow]

TODO work on phrasing; #106

Proposal accepted, and believe concerns have been addressed.