Jon Meow
d031f3cdab
Co-authored by: chandlerc - Based on [PR 22](https://github.com/carbon-language/carbon-lang/pull/83) - [Idea topic](https://forums.carbon-lang.dev/t/proposal-for-an-incomplete-rough-high-level-overview-ready-for-early-feedback/52) - [RFC](https://forums.carbon-lang.dev/t/rfc-an-incomplete-early-and-in-progress-overview-of-the-language-design/73) - [Decision announcement](https://forums.carbon-lang.dev/t/accepted-an-incomplete-early-and-in-progress-overview-of-the-language-design/110) This proposal should be considered a starting point of the language design. It's not intended to be final; language details may change. This is intended to offer a reasonable starting point for: - Example code. - Conceptualizing Carbon at a high level. - Reasonable, but not necessarily final, approaches to features in README.md. - If any idea is obviously bad, we can clean it up here. This proposal is not intended to achieve: - A whole language design. - This is way too much work for a single proposal; this is a skeletal framework only. - As we work on feature-specific designs, we may decide to use other approaches. That's fine: we only need somewhere to start. - The summaries in README.md may be expected to change over time. - Feature-specific files aren't intended to be well-written or comprehensive. They are a quick jot of prior thoughts. - We want to avoid getting stuck on language details that we should consider more carefully regardless. If you're passionate about a feature, please feel free to start a new proposal for it. - Each and every aspect of the suggested overview should be subject to careful examination and justification before it becomes a settled plan of record. Chandler started this with https://github.com/carbon-language/carbon-lang/pull/22. I've taken it over with the following changes: - More of a directory hierarchy. - Trying to thin out the main file (now README.md) to lighter summaries of features. - Details/rationale/alternatives should be in feature-specific files. - Draft files are linked as references where added. For an example of how we may proceed with feature-specific designs, see https://github.com/carbon-language/carbon-lang/pull/80. In this structure: - docs/design/README.md mentions interoperability, with a light overview. - The light overview is not yet in https://github.com/carbon-language/carbon-lang/pull/80. - docs/design/interoperability/README.md goes into more depth on interoperability, covering key points of the approach. - Individual files in docs/design/interoperability/* go into more depth on interoperability. Simple designs may not have a subdirectory. All current feature-specific designs do not -- they may be moved later.
3.4 KiB
Syntactic conventions
Table of contents
TODO
This is a skeletal design, added to support the overview. It should not be treated as accepted by the core team; rather, it is a placeholder until we have more time to examine this detail. Please feel welcome to rewrite and update as appropriate.
Overview
Right now we expect variable syntax like: Int: x.
There are probably other syntactic conventions that can be added here, too.
Alternatives
Types before or after name
While we are currently keeping types first, matching C++, there is significant uncertainty around the right approach here. While adding the colon improves the grammar by unambiguously marking the transition from type to a declared identifier, in essentially every other language with a colon in a similar position, the identifier is first and the type follows. However, that ordering would be very inconsistent with C++.
One very important consideration here is the fundamental approach to type
inference. Languages which use the syntax <identifier>: <type> typically allow
completely omitting the colon and the type to signify inference. With C++,
inference is achieved with a placeholder keyword auto, and Carbon is currently
being consistent there as well with auto: <identifier>. For languages which
simply allow omission, this seems an intentional incentive to encourage
inference. On the other hand, there has been strong advocacy in the C++
community to not overly rely on inference and to write the explicit type
whenever convenient. Being consistent with the ordering of identifier and type
may ultimately be less important than being consistent with the incentives and
approach to type inference. What should be the default that we teach? Teaching
to avoid inference unless it specifically helps readability by avoiding a
confusing or unhelpfully complex type name, and incentivizing that by requiring
auto or another placeholder, may cause as much or more inconsistency with
languages that use <identifier>: <type> as retaining the C++ ordering.
That said, all of this is largely unknown. It will require a significant exploration of the trade-offs and consistency differences. It should also factor in further development of pattern matching generally and whether that has an influence on one or another approach. Last but not least, while this may seem like something that people will get used to with time, it may be worthwhile to do some user research to understand the likely reaction distribution, strength of reaction, and any quantifiable impact these options have on measured readability. We have only found one very weak source of research that focused on the order question (rather than type inference vs. explicit types or other questions in this space). That was a very limited PhD student's study of Java programmers that seemed to indicate improved latency for recalling the type of a given variable name with types on the left (as in C++). However, those results are far from conclusive.
TODO: Get a useful link to this PhD research (a few of us got a copy from the professor directly).