Checked and template generic terminology #2138
Conversation
josh11b
added
proposal
github-actions
bot
added
proposal rfc
There was a problem hiding this comment.
As a proposal, shouldn't this offer some rationale for switching? @chandlerc @zygoloid I see you thumbs-upped this proposal, is this good enough for the leads?
I think the "Problem" section outlines the primary rationale I have for liking this change. And I think its wording maps pretty cleanly to the specific goals cited in the rationale section? Happy to add more detail here if needed though. |
| since our documentation governing the interpretation of that code will be | ||
| more easily understood and with greater accuracy. | ||
| - [Interoperability with and migration from existing C++ code](/docs/project/goals.md#interoperability-with-and-migration-from-existing-c-code) | ||
| since there will be a smaller terminology gap between Carbon and C++. |
There was a problem hiding this comment.
Isn't this just shifting the terminology gap, because "templates" are now "template generics"? How does this reduce the terminology gap?
There was a problem hiding this comment.
I think the specific improvement is that in C++, people talk about doing generic programming with templates, and with this shift in terminology you can talk about doing generic programming with template [generic]s in Carbon too.
| since our documentation governing the interpretation of that code will be | ||
| more easily understood and with greater accuracy. | ||
| - [Interoperability with and migration from existing C++ code](/docs/project/goals.md#interoperability-with-and-migration-from-existing-c-code) | ||
| since there will be a smaller terminology gap between Carbon and C++. |
There was a problem hiding this comment.
I think the specific improvement is that in C++, people talk about doing generic programming with templates, and with this shift in terminology you can talk about doing generic programming with template [generic]s in Carbon too.
Co-authored-by: Richard Smith <[email protected]>
Co-authored-by: Richard Smith <[email protected]>
There was a problem hiding this comment.
Thank you for adding alternatives. I'll continue to respectfully disagree that "template generics" is lowering the terminology gap versus "templates" for C++ developers (Carbon was probably the first time I really thought about "generic programming" beyond either templates or generics), but I think my structural proposal concerns have been addressed.
josh11b
added
proposal accepted
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 #2138 , plus a number of other updates, including reflecting that we have decided to include templates in Carbon.
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]>
First step in updating `docs/design/generics/details.md`. It incorporates changes from proposals: #989 #2138 #2173 #2200 #2360 #2964 #3162 , but there are still more changes from those proposals to be made. It also switches away from suggesting static-dispatch witness tables, and creates an appendix to describe that decision. --------- 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]>
Continued from part 1: #3231. Second step updating `docs/design/generics/details.md`. There remains some work to incorporate proposal #2200. - The biggest changes are incorporating much of the text of proposals: - #2173 - #2687 - It incorporates changes from proposals: - #989 - #1178 - #2138 - #2200 - #2360 - #2964 - #3162 - It also updates the text to reflect the latest thinking from leads issues: - #996 - #2153 -- most notably deleting the section on `TypeId`. - Update to rule for prioritization blocks with mixed type structures from [discussion on 2023-07-18](https://docs.google.com/document/d/1gnJBTfY81fZYvI_QXjwKk1uQHYBNHGqRLI2BS_cYYNQ/edit?resourcekey=0-ql1Q1WvTcDvhycf8LbA9DQ#heading=h.7jxges9ojgy3) - Adds reference links to proposals, issues, and discussions relevant to the text. - 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 - #2483 --------- Co-authored-by: Richard Smith <[email protected]>
Change terminology from "generics" and "templates" to "checked generics" and "template generics". Afterwards, "generics" will be an umbrella term that include templates.