-
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
Types are values of type type
#2360
Types are values of type type
#2360
Conversation
b0f0ff6
to
7cf53a2
Compare
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.
I did a quick review while its still fresh in my mind, and this largely matches my understanding of our discussions!
I'm pretty happy w/ the improved story across the board here. A somewhat minor added bit of prose suggested inline.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Add a bunch 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.
Approving for leads, this seems ready to land.
FWIW, I do think there are two things to keep our eyes on:
-
As mentioned in the proposal, we may need to revisit the whole tuple situation if this approach proves too confusing. But I think that's a fine fix-forward to keep open.
-
We may want to revisit or tweak the precise terminology. I even have some ideas of what might be an improvement here, but they seem better considered as incremental changes in the future rather than trying to keep iterating here.
If Josh is happy merging my typo fix, one of us can likely merge the whole PR afterward.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
…or review comments.
Also make minor updates to the skeletal design in docs/design/name_lookup.md following carbon-language#2113, as there are no longer any prelude names that are made available to unqualified name lookup by default. Add `type` to the keyword list in docs/design/lexical_conventions/words.md, following carbon-language#2360.
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 <gromer@google.com> Co-authored-by: Richard Smith <richard@metafoo.co.uk>
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 <richard@metafoo.co.uk>
Change terminology away from terms that are ambiguous: - Reserve "generic type" for types with (compile-time) parameters, like `Vector` in `Vector(T:! type)`. Don't use that term to refer to `T`, as it would with [#2360](https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p2360.md#terminology). - Use the term "compile-time" instead of "constant" to mean "template or symbolic." Expand the term "constant" to include values, such as from `let` bindings.
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 <richard@metafoo.co.uk>
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 <chandlerc@gmail.com>
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 <richard@metafoo.co.uk>
Define a "type" to be a value of type
type
. Contexts expecting a type perform an implicit conversion totype
. Values like()
and(i32, i32)
and{}
are no longer types, but instead implicitly convert totype
. Values of interface or constraint type (now called "facets") are similarly not formally types but implicitly convert totype
.