-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consistent class
and interface
syntax
#2760
Conversation
Please pay particular attention to the alternatives, I'm not sure that I have captured everything important we considered in #995 . |
I have a draft PR #2866 for updating the syntax in the design docs, if you would like to see how this looks in a number of examples. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this looks good and aligned with previous discussion and answers to questions-for-leads.
Co-authored-by: Richard Smith <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't had time to fully work through, but wanted to at least respond to some of the open threads here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving on behalf of leads. This reflects decisions from prior leads issues, with a scope reduction for require
that @chandlerc and I are both happy with and that seems to generally improve consensus. Thanks!
Implement syntax changes from #2760 in Explorer
This includes: - Syntax changes from this chart: | Before | After | | ------------------------------- | --------------------------------------- | | `class D extends B { ... }` | `class D { extend base: B; ... }` | | `external impl C as Sub;` | `impl C as Sub;` | | `class C { impl as Sortable; }` | `class C { extend impl as Sortable; }` | | `adapter A for C { ... }` | `class A { adapt C; ... }` | | `adapter A extends C { ... }` | `class A { extend adapt C; ... }` | | `interface I { impl as J; }` | `interface I { require Self impls J; }` | | `interface I { extends J; }` | `interface I { extend J; }` | - Dropping the syntax for conditionally implemented internal interfaces. This does not include: - terminology changes from #2760 ("internal" and "external") - changes to code, such as explorer, toolchain, language grammars, or other tooling
This reflects changes from a number of approved proposals: - #920 : concrete statements about orphan and overlap in Carbon - #2138 : "generic" -> "checked generic", "template" -> "template generic" - #2188 : binding patterns are forbidden in type position - #2360 : "type", "facet type", "facet". Note: I am not using the term "generic type" from #2360 since that meaning conflicts with the generally accepted meaning of "generic type" of a type with a compile-time parameter. - #2760 / #2770 : internal/external impl -> extending impl - #2964 : "symbolic constant" and "template constant" --------- Co-authored-by: Geoff Romer <[email protected]> Co-authored-by: Richard Smith <[email protected]>
This reflects changes from a number of approved proposals: - #2138 : "generic" -> "checked generic", "template" -> "template generic" - #2360 : "type", "facet type", "facet". Note: I am not using the term "generic type" from #2360 since that meaning conflicts with the generally accepted meaning of "generic type" of a type with a compile-time parameter. - #2760 / #2770 : internal/external impl -> extending impl - #2964 : "symbolic constant" and "template constant" --------- Co-authored-by: Richard Smith <[email protected]>
Includes proposals: - #990 - #2188 - #2138 - #2200 - #2360 - #2760 - #2964 - #3162 Also tries to use more precise language when talking about: - implementations, to avoid confusing `impl` declaration and definitions with the `impls` operator used in `where` clauses, an issue brought up in #2495 and #2483; - "binding patterns", like `x: i32`, and "bindings" like `x`. --------- Co-authored-by: Chandler Carruth <[email protected]>
…4401) Note: some of this is from the principle of information accumulation, and some is from [proposal #2760](https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p2760.md#class-inheritance). Also: change terminology from "virtual override keywords" to "virtual modifier keywords", to be consistent with our other modifier keywords. --------- Co-authored-by: Josh L <[email protected]>
Update syntax of
class
andinterface
definitions to be more consistent. Constructs that add names to the class or interface from another definition are always prefixed by theextend
keyword.Implements the decisions in: