-
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
Generics goals #24
Generics goals #24
Conversation
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.
Looking nice. I'd be happy for this to move into the RFC phase as soon as the new process is in place...
Commit suggestions from chandlerc's review Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
There seem to be too many specifics and implementation details in this document for it to be a principle document. It is just my opinion, but I think it would be more appropriate for a principle document to explain the requirements and use cases (generic programming? DSLs? metaprogramming? compatibility with C++?), justify the necessity for both generics and templates in one language, explain the desired place in the language and idiomatic usage patterns for both etc. |
Another point that would be important to discuss in a high-level doc is whether we want generics to be always monomorphizable. For example, some corner cases of Swift generics can't be monomorphized, even though the vast, vast majority can be. (If you are curious, cases that can't be monomorphized are related to polymorphic recursion https://forums.swift.org/t/ergonomics-generic-types-conforming-in-more-than-one-way/34589/71 or https://stackoverflow.com/questions/40247339/polymorphic-recursion-syntax-and-uses.) |
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 think this LGTM now.
However, I'd somewhat prefer to land the script changes as their own PR first, so this change can just introduce the goals for generics. Is that do-able? Would that be super disruptive?
@chandlerc The script changes are because the tests have hard-coded text with the first accepted proposal by number, and this PR has a number less than all the previously accepted ones. So the tests need to be changed at the same time. |
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.
Awesome, now that I'm not misunderstanding the script changes, definitely LGTM to me!
This adds an overview of a generics feature that attempts to achieve the goals from #24 . It has been summarized in these presentations: - [non-type params](https://docs.google.com/presentation/d/1IZaDxP5Y3Wqprkyjzagv48tyxEeIcfz8FZS3Namsvew/edit#slide=id.p) - [basic usage](https://docs.google.com/presentation/d/1OZiMTVW2Ommop5WTs9RyEwnGxy9yzaAPF7Cj5KUfDsY/edit?resourcekey=0-Nya0Soz3ZNs3hJan8VIrTA#slide=id.p) - [more advanced usage](https://docs.google.com/presentation/d/1bg6q0Q9Sk4YpRbNA3D3H34xYtaEO8ScAUNUZK2UTi80/edit?resourcekey=0-6-Y6e1mfRUmHg-Zk65Gc5A#slide=id.p) Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com> Co-authored-by: Chandler Carruth <chandlerc@gmail.com> Co-authored-by: Wolff Dobson <wolffg@users.noreply.github.com>
This proposal goes into the details of the core of the generics feature, to achieve the goals from #24 , and provides an outline covering future work. It has been summarized in these presentations: - [basic usage](https://docs.google.com/presentation/d/1OZiMTVW2Ommop5WTs9RyEwnGxy9yzaAPF7Cj5KUfDsY/edit?resourcekey=0-Nya0Soz3ZNs3hJan8VIrTA#slide=id.p) - [details: interfaces](https://docs.google.com/presentation/d/1FSlqtE5hXZIwOO52UrAK9DINBLDWtgu24dugHfomUMg/edit#slide=id.p) - [details: facet types](https://docs.google.com/presentation/d/17KG0TeJ4OChMRdLJPS8TE_K6SoL4lFy1FUGr2CDzX-A/edit?resourcekey=0-kLnZqd5NrbGSwmbunTyB-A#slide=id.p) - [details: type-types](https://docs.google.com/presentation/d/1Hn3VDlVjwhjx3SKM2KXKE7lW208nXff30x3-uIO4_Fo/edit#slide=id.p) - [details: extending/refining interfaces](https://docs.google.com/presentation/d/1K0cCHeb9JTJY9QCGEVO9CcJNHYlaXkoPESv4J9tl5LU/edit#slide=id.p) Co-authored-by: Richard Smith <richard@metafoo.co.uk>
The "generics" feature of Carbon is a large design effort that needs to be broken up into manageable steps. The first thing we need is a high-level goals document. The goals here reflect the desirable properties that we have discovered as part of considering several alternative generics designs: - Use cases: - Generic programming - Upgrade path from C++ abstract interfaces - Dependency injection - Generics instead of open overloading and ADL - Performance - Better compiler experience - Encapsulation - Predictability - Dispatch control - Upgrade path from templates - Coherence - No novel name lookup - Learn from others - Interfaces are nominal - Interop and evolution - Bridge for C++ customization points Goals are summarized in [this presentation](https://docs.google.com/presentation/d/12yGyu5Pvdag7CJp-_yLVkmbhyvuRIilBTNlkO0LKaHo/edit?usp=sharing&resourcekey=0-JB9yrUO4-6J8-zzGhnIyNg). Co-authored-by: Chandler Carruth <chandlerc@gmail.com> Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com> Co-authored-by: Matthew Riley <mdriley@gmail.com> Co-authored-by: austern <austern@google.com> Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
This adds an overview of a generics feature that attempts to achieve the goals from #24 . It has been summarized in these presentations: - [non-type params](https://docs.google.com/presentation/d/1IZaDxP5Y3Wqprkyjzagv48tyxEeIcfz8FZS3Namsvew/edit#slide=id.p) - [basic usage](https://docs.google.com/presentation/d/1OZiMTVW2Ommop5WTs9RyEwnGxy9yzaAPF7Cj5KUfDsY/edit?resourcekey=0-Nya0Soz3ZNs3hJan8VIrTA#slide=id.p) - [more advanced usage](https://docs.google.com/presentation/d/1bg6q0Q9Sk4YpRbNA3D3H34xYtaEO8ScAUNUZK2UTi80/edit?resourcekey=0-6-Y6e1mfRUmHg-Zk65Gc5A#slide=id.p) Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com> Co-authored-by: Chandler Carruth <chandlerc@gmail.com> Co-authored-by: Wolff Dobson <wolffg@users.noreply.github.com>
This proposal goes into the details of the core of the generics feature, to achieve the goals from #24 , and provides an outline covering future work. It has been summarized in these presentations: - [basic usage](https://docs.google.com/presentation/d/1OZiMTVW2Ommop5WTs9RyEwnGxy9yzaAPF7Cj5KUfDsY/edit?resourcekey=0-Nya0Soz3ZNs3hJan8VIrTA#slide=id.p) - [details: interfaces](https://docs.google.com/presentation/d/1FSlqtE5hXZIwOO52UrAK9DINBLDWtgu24dugHfomUMg/edit#slide=id.p) - [details: facet types](https://docs.google.com/presentation/d/17KG0TeJ4OChMRdLJPS8TE_K6SoL4lFy1FUGr2CDzX-A/edit?resourcekey=0-kLnZqd5NrbGSwmbunTyB-A#slide=id.p) - [details: type-types](https://docs.google.com/presentation/d/1Hn3VDlVjwhjx3SKM2KXKE7lW208nXff30x3-uIO4_Fo/edit#slide=id.p) - [details: extending/refining interfaces](https://docs.google.com/presentation/d/1K0cCHeb9JTJY9QCGEVO9CcJNHYlaXkoPESv4J9tl5LU/edit#slide=id.p) Co-authored-by: Richard Smith <richard@metafoo.co.uk>
The "generics" feature of Carbon is a large design effort that needs to be
broken up into manageable steps. The first thing we need is a high-level goals
document. The goals here reflect the desirable properties that we have discovered as
part of considering several alternative generics designs:
Goals are summarized in this presentation.