├── .gitattributes ├── .github ├── ISSUE_TEMPLATE │ ├── active_initiative.md │ └── meeting-proposal.md └── workflows │ └── deploy.yml ├── .gitignore ├── CODE_OF_CONDUCT.md ├── LICENSE-APACHE ├── LICENSE-MIT ├── README.md ├── book.toml ├── design-meeting-minutes ├── 2020-01-06-Pin-unsoundness.md ├── 2020-01-13-dyn-trait-and-coherence.md ├── 2020-02-03-specialization-review.md ├── 2020-02-10-References-and-dereferenceable.md ├── 2020-03-16-ffi-unwind.md ├── 2020-03-23-sealed-rust.md ├── 2020-04-20-2021-edition-design.md ├── 2020-06-24-const-eval-unsafe-and-skill-tree.md ├── 2020-07-01-safe-transmute-typic.md ├── 2020-07-08-lang-team-path-to-membership.md ├── 2020-07-22-Const-generics-MVP.md ├── 2020-07-29-wf-checks-and-ty-aliases.md ├── 2020-08-26-stream-trait.md ├── 2020-11-04-RFC-2580-and-custom-dst.md ├── 2020-11-18-understanding-memoryand-thread-safety-practices-and-issues-in-real-world-rust-programs.md ├── 2021-01-20-RFC-2229.md ├── 2021-02-03-Planning-Meeting.md ├── 2021-02-17-Increasing-Trust-in-Rust-Compiler.md ├── 2021-02-24-lints-and-editions.md ├── 2021-03-03-Planning-Meeting.md ├── 2021-03-24-lang-team-organization.md ├── 2021-03-31-how-to-dismantle-an-atomic-bomb.md ├── 2021-04-14-Planning-Meeting.md ├── 2021-04-21-wasm-abi.md ├── 2021-05-12-Generators.md ├── 2021-05-19-May-updates.md ├── 2021-05-26-Rust-guiding-principles.md ├── 2021-06-02-planning-meeting.md ├── 2021-06-30-lang-team-projects.md ├── 2021-07-07-Planning-meeting.md ├── 2021-07-21-decision-making-tenets-and-process.md ├── 2021-07-28-structural-equality.md ├── 2021-09-01-Planning-meeting.md ├── 2021-09-22-GAT-defaults.md ├── 2021-10-06-Planning-meeting.md ├── 2021-10-13-where-the-where.md ├── 2021-10-20-dyn-upcast-and-safety.md ├── 2021-11-03.md ├── 2021-11-17-named-fn-types.md ├── 2021-12-01-Planning-Meeting.md ├── 2021-12-22-Const-eval-update.md ├── 2022-01-05-Design-meeting-minutes.md ├── 2022-02-02-planning.md ├── 2022-02-16-libs-most-wanted.md ├── 2022-03-02-planning-meeting.md ├── 2022-03-09-lang-roadmap.md ├── 2022-03-23-async-fn-and-rpitit.md ├── 2022-03-30-lint-policy.md ├── 2022-03-30-lints.md ├── 2022-04-12-implied-bounds-and-perfect-derive.md ├── 2022-08-31-gat-stabilization.md ├── 2022-10-05-provenance.md ├── 2022-11-25-contracts.md ├── 2023-01-08-lang-team-questions-around-contracts.md ├── 2023-03-15-temporary-lifetimes.md ├── 2023-05-17-rpitit-stabilization-schedule.md ├── 2023-05-24-return-type-notation.md └── 2023-05-31-TAIT-stabilization.md ├── mermaid-init.js ├── mermaid.min.js ├── minutes ├── 2019-03-14.md ├── 2019-04-18.md ├── 2019-06-06.md ├── 2019-09-26.md ├── 2019-10-03.md ├── 2019-10-10.md ├── 2019-10-17.md ├── 2019-10-24.md ├── 2019-10-31.md ├── 2019-11-07.md ├── 2019-11-14.md ├── 2019-11-21.md ├── 2019-12-05.md ├── 2019-12-12.md ├── 2019-12-19.md ├── 2019.04.18.md ├── 2019.09.26.md ├── 2020-01-02.md ├── 2020-01-09.md ├── 2020-01-16.md ├── 2020-01-23.md ├── 2020-02-06.md ├── 2020-02-27.md ├── 2020-03-05.md ├── 2020-03-12.md ├── 2020-03-19.md ├── 2020-03-26.md ├── 2020-04-02.md ├── 2020-04-09.md ├── 2020-04-30.md ├── 2020-06-01.md ├── 2020-06-08.md ├── 2020-06-15.md ├── 2020-06-22.md ├── 2020-06-29.md ├── 2020-07-06.md ├── 2020-07-20.md ├── 2020-07-27.md ├── 2020-08-03.md ├── 2020-09-14.md ├── 2020-09-21.md ├── 2020-09-28.md ├── 2020-10-12.md ├── 2020-10-19.md ├── 2020-10-26.md ├── 2020-11-02.md ├── 2020-11-10.md ├── 2020-11-17.md ├── 2020-12-01.md ├── 2021-01-05.md ├── 2021-01-12.md ├── 2021-01-19.md ├── 2021-01-26.md ├── 2021-02-02.md ├── 2021-02-09.md ├── 2021-02-16.md ├── 2021-02-23.md ├── 2021-03-02.md ├── 2021-03-09.md ├── 2021-03-16.md ├── 2021-03-23.md ├── 2021-03-30.md ├── 2021-04-06.md ├── 2021-04-20.md ├── 2021-04-27.md ├── 2021-05-04.md ├── 2021-05-11.md ├── 2021-05-25.md ├── 2021-06-01.md ├── 2021-06-15.md ├── 2021-06-22.md ├── 2021-06-29.md ├── 2021-07-06.md ├── 2021-07-13.md ├── 2021-08-24.md ├── 2021-08-31.md ├── 2021-09-21.md ├── 2021-09-28.md ├── 2021-10-12.md ├── 2021-10-19.md ├── 2021-11-02.md ├── 2021-11-09.md ├── 2021-11-16.md ├── 2022-01-04.md ├── 2022-01-18.md ├── 2022-01-25-Triage-minutes.md ├── 2022-02-01.md ├── 2022-02-08.md ├── 2022-02-15.md ├── 2022-03-01.md ├── 2022-03-08.md ├── 2022-03-15.md ├── 2022-03-22.md ├── 2022-05-10.md ├── 2022-05-17.md ├── 2022-05-31.md ├── 2022-06-14.md ├── 2022-06-28.md ├── 2022-07-12.md ├── 2022-08-16.md ├── 2022-09-06.md ├── 2022-09-13.md ├── 2022-09-20.md ├── 2022-09-27.md ├── 2022-10-04.md ├── 2022-10-11.md ├── 2022-10-18.md ├── 2022-10-25.md ├── 2022-11-01.md ├── 2022-11-08.md ├── 2022-11-15.md └── 2022-11-22.md ├── projects ├── README.md ├── const-generics.md ├── declarative-macro-repetition-counts │ ├── 0000-draft-rfc.md │ └── charter.md └── deref-patterns.md ├── src ├── SUMMARY.md ├── backlog-bonanza.md ├── calendar.md ├── chat_platform.md ├── decision_process.md ├── decision_process │ ├── examples.md │ └── reference.md ├── design-meeting.md ├── design_notes.md ├── design_notes │ ├── auto_traits.md │ ├── autoref_ops.md │ ├── copy_ergonomics.md │ ├── dynsized_constraints.md │ ├── eager_drop.md │ ├── fn_type_trait_impls.md │ ├── general_coroutines.md │ ├── int_literal_as_float.md │ └── variadic_generics.md ├── frequently-requested-changes.md ├── how_to.md ├── how_to │ ├── design_meeting.md │ ├── experiment.md │ ├── new_lint.md │ ├── nominate.md │ ├── propose.md │ └── stabilize.md ├── initiatives.md ├── language-change-policy.md ├── leads.md ├── meetings.md ├── meetings │ ├── backlog-bonanza.md │ ├── design.md │ └── triage.md ├── membership.md ├── roadmaps.md ├── roadmaps │ └── roadmap-2024.md └── welcome.md ├── triagebot.toml └── working-groups ├── README.md ├── grammar ├── NOTES.md └── README.md ├── meta ├── README.md └── minutes │ ├── 2019.05.02.md │ ├── 2019.05.09.md │ ├── 2019.05.30.md │ └── 2019.06.06.md └── unsafe-code-guidelines ├── NOTES.md ├── README.md └── notes └── 2019-03-14.md /.gitattributes: -------------------------------------------------------------------------------- 1 | # Not useful to get grep results from 2 | mermaid.min.js binary 3 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/active_initiative.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Active initiative tracking issue 3 | about: Issue representing an active initiative 4 | title: "(My meeting proposal)" 5 | labels: lang-initiative, T-lang 6 | assignees: "" 7 | --- 8 | 9 | # Summary 10 | 11 | _Briefly describe the goal of the initiative_ 12 | 13 | # Info 14 | 15 | - Owner: _name here_ 16 | - Liaison: _name here_ 17 | - Zulip stream [`#project-XXX`](XXX) 18 | - [stage]: Experimental 19 | - Repository [rust-lang/XXX](https://github.com/rust-lang/XXX) (if any) 20 | 21 | [Stage] 22 | 23 | # What is this issue? 24 | 25 | This issue represents an **[active initiative]**. It is meant to be used for 26 | the group to post updates to the lang team (and others) in a lightweight 27 | fashion. Please do not use the comments here for discussion, that should be kept 28 | in the Zulip stream (discussion comments here will be marked as off-topic). 29 | 30 | [stage]: https://lang-team.rust-lang.org/initiatives/stages.md 31 | [active initiative]: https://lang-team.rust-lang.org/initiatives.md 32 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/meeting-proposal.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Design meeting proposal 3 | about: Propose a topic for the design meeting. 4 | title: "Design meeting: (My meeting proposal)" 5 | labels: meeting-proposal, T-lang 6 | assignees: '' 7 | 8 | --- 9 | 10 | # Summary 11 | 12 | *Please describe your meeting topic here. It doesn't have to be very long, but 13 | it's always good to try and identify a concrete question to be answered or 14 | narrow topic for discussion. Nobody likes a rambly meeting.* 15 | 16 | # Background reading 17 | 18 | *Include any links to material that folks ought to try to read before-hand.* 19 | 20 | # About this issue 21 | 22 | This issue corresponds to a [lang-team design meeting proposal]. It corresponds to a possible topic of discussion that may be scheduled for deeper discussion during one of our design meetings. 23 | 24 | [lang-team design meeting proposal]: https://lang-team.rust-lang.org/meetings/design.html 25 | -------------------------------------------------------------------------------- /.github/workflows/deploy.yml: -------------------------------------------------------------------------------- 1 | name: Deploy mdBook 2 | on: [push] 3 | jobs: 4 | build: 5 | runs-on: ubuntu-latest 6 | steps: 7 | - uses: actions/checkout@v2 8 | - name: Install mdbook-mermaid 9 | run: cargo install mdbook-mermaid 10 | - name: Setup mdBook 11 | uses: peaceiris/actions-mdbook@v1 12 | with: 13 | mdbook-version: '0.4.35' 14 | - run: mdbook build 15 | - name: Deploy 16 | uses: peaceiris/actions-gh-pages@v3 17 | if: ${{ github.ref == 'refs/heads/master' }} 18 | with: 19 | github_token: ${{ secrets.GITHUB_TOKEN }} 20 | publish_dir: ./book 21 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | book 2 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # The Rust Code of Conduct 2 | 3 | A version of this document [can be found online](https://www.rust-lang.org/conduct.html). 4 | 5 | ## Conduct 6 | 7 | **Contact**: [rust-mods@rust-lang.org](mailto:rust-mods@rust-lang.org) 8 | 9 | * We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic. 10 | * On IRC, please avoid using overtly sexual nicknames or other nicknames that might detract from a friendly, safe and welcoming environment for all. 11 | * Please be kind and courteous. There's no need to be mean or rude. 12 | * Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer. 13 | * Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works. 14 | * We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behavior. We interpret the term "harassment" as including the definition in the Citizen Code of Conduct; if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don't tolerate behavior that excludes people in socially marginalized groups. 15 | * Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops or any of the [Rust moderation team][mod_team] immediately. Whether you're a regular contributor or a newcomer, we care about making this community a safe place for you and we've got your back. 16 | * Likewise any spamming, trolling, flaming, baiting or other attention-stealing behavior is not welcome. 17 | 18 | ## Moderation 19 | 20 | 21 | These are the policies for upholding our community's standards of conduct. If you feel that a thread needs moderation, please contact the [Rust moderation team][mod_team]. 22 | 23 | 1. Remarks that violate the Rust standards of conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed. (Cursing is allowed, but never targeting another user, and never in a hateful manner.) 24 | 2. Remarks that moderators find inappropriate, whether listed in the code of conduct or not, are also not allowed. 25 | 3. Moderators will first respond to such remarks with a warning. 26 | 4. If the warning is unheeded, the user will be "kicked," i.e., kicked out of the communication channel to cool off. 27 | 5. If the user comes back and continues to make trouble, they will be banned, i.e., indefinitely excluded. 28 | 6. Moderators may choose at their discretion to un-ban the user if it was a first offense and they offer the offended party a genuine apology. 29 | 7. If a moderator bans someone and you think it was unjustified, please take it up with that moderator, or with a different moderator, **in private**. Complaints about bans in-channel are not allowed. 30 | 8. Moderators are held to a higher standard than other community members. If a moderator creates an inappropriate situation, they should expect less leeway than others. 31 | 32 | In the Rust community we strive to go the extra step to look out for each other. Don't just aim to be technically unimpeachable, try to be your best self. In particular, avoid flirting with offensive or sensitive issues, particularly if they're off-topic; this all too often leads to unnecessary fights, hurt feelings, and damaged trust; worse, it can drive people away from the community entirely. 33 | 34 | And if someone takes issue with something you said or did, resist the urge to be defensive. Just stop doing what it was they complained about and apologize. Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could've communicated better — remember that it's your responsibility to make your fellow Rustaceans comfortable. Everyone wants to get along and we are all here first and foremost because we want to talk about cool technology. You will find that people will be eager to assume good intent and forgive as long as you earn their trust. 35 | 36 | The enforcement policies listed above apply to all official Rust venues; including official IRC channels (#rust, #rust-internals, #rust-tools, #rust-libs, #rustc, #rust-beginners, #rust-docs, #rust-community, #rust-lang, and #cargo); GitHub repositories under rust-lang, rust-lang-nursery, and rust-lang-deprecated; and all forums under rust-lang.org (users.rust-lang.org, internals.rust-lang.org). For other projects adopting the Rust Code of Conduct, please contact the maintainers of those projects for enforcement. If you wish to use this code of conduct for your own project, consider explicitly mentioning your moderation policy or making a copy with your own moderation policy so as to avoid confusion. 37 | 38 | *Adapted from the [Node.js Policy on Trolling](http://blog.izs.me/post/30036893703/policy-on-trolling) as well as the [Contributor Covenant v1.3.0](https://www.contributor-covenant.org/version/1/3/0/).* 39 | 40 | [mod_team]: https://www.rust-lang.org/team.html#Moderation-team 41 | -------------------------------------------------------------------------------- /LICENSE-MIT: -------------------------------------------------------------------------------- 1 | Permission is hereby granted, free of charge, to any 2 | person obtaining a copy of this software and associated 3 | documentation files (the "Software"), to deal in the 4 | Software without restriction, including without 5 | limitation the rights to use, copy, modify, merge, 6 | publish, distribute, sublicense, and/or sell copies of 7 | the Software, and to permit persons to whom the Software 8 | is furnished to do so, subject to the following 9 | conditions: 10 | 11 | The above copyright notice and this permission notice 12 | shall be included in all copies or substantial portions 13 | of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF 16 | ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 17 | TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A 18 | PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT 19 | SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY 20 | CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION 21 | OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR 22 | IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 23 | DEALINGS IN THE SOFTWARE. 24 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # lang-team 2 | 3 | A home for the Rust language design team. The language design team is 4 | generally responsible for decisions involving the design of the Rust 5 | language itself, such as its syntax, semantics, or specification. This 6 | repository houses planning documents, meeting minutes, and other such 7 | things. 8 | 9 | ## Rendered form 10 | 11 | Visit the rendered form of this site at [lang-team.rust-lang.org](https://lang-team.rust-lang.org/). 12 | 13 | ## Code of Conduct and licensing 14 | 15 | All interactions on this repository (whether on issues, PRs, or 16 | elsewhere) are governed by the [Rust Code of 17 | Conduct](CODE_OF_CONDUCT.md). 18 | 19 | Further, all content on this repository is subject to the standard 20 | [Rust](LICENSE-MIT) [licensing](LICENSE-APACHE). 21 | -------------------------------------------------------------------------------- /book.toml: -------------------------------------------------------------------------------- 1 | [book] 2 | authors = ["Niko Matsakis"] 3 | language = "en" 4 | multilingual = false 5 | src = "src" 6 | title = "The Rust Language Design Team" 7 | 8 | [output.html] 9 | additional-js =["mermaid.min.js", "mermaid-init.js"] 10 | cname = "lang-team.rust-lang.org" 11 | git-repository-url = "https://github.com/rust-lang/lang-team" 12 | edit-url-template = "https://github.com/rust-lang/lang-team/edit/master/{path}" 13 | 14 | [output.html.fold] 15 | enable = true 16 | level = 0 17 | 18 | [preprocessor] 19 | [preprocessor.mermaid] 20 | command = "mdbook-mermaid" 21 | 22 | [output.html.redirect] 23 | "/rust-2018/edition-changes.html" = "index.html" 24 | "/priorities.html" = "initiatives/priorities.html" 25 | "/project_groups.html" = "initiatives/active.html" 26 | "/proposing_a_project.html" = "initiatives/proposing.html" 27 | "/initiatives.html" = "how_to/propose.html" 28 | "/initiatives/faq.html" = "how_to/propose.html" 29 | "/initiatives/priorities.html" = "how_to/propose.html" 30 | "/initiatives/process/checklists.html" = "how_to/propose.html" 31 | "/initiatives/process/roles/liaison.html" = "how_to/experiment.html" 32 | "/initiatives/process/roles/owner.html" = "how_to/experiment.html" 33 | "/initiatives/process/roles.html" = "how_to/propose.html" 34 | "/initiatives/process/stages/development.html" = "how_to/propose.html" 35 | "/initiatives/process/stages/experimental.html" = "how_to/experiment.html" 36 | "/initiatives/process/stages/feature_complete.html" = "how_to/propose.html" 37 | "/initiatives/process/stages/inactive.html" = "how_to/propose.html" 38 | "/initiatives/process/stages/proposal.html" = "how_to/propose.html" 39 | "/initiatives/process/stages/stabilized.html" = "how_to/propose.html" 40 | "/initiatives/process/stages.html" = "how_to/propose.html" 41 | "/initiatives/process.html" = "how_to/propose.html" 42 | "/initiatives/stable.html" = "how_to/propose.html" 43 | -------------------------------------------------------------------------------- /design-meeting-minutes/2020-04-20-2021-edition-design.md: -------------------------------------------------------------------------------- 1 | # 2021 Edition Design Meeting 2 | 3 | * [recording](https://www.youtube.com/watch?v=uDbs_1LXqus) 4 | 5 | Changes prepping for the edition should all start materializing by October it 6 | seems, based on comments throughout the meeting 7 | 8 | ## Implied bounds 9 | 10 | Apparently there are API compatibility hazards here, where if implied bounds 11 | are depended upon by an external crate removing a bound from the struct would 12 | be a breaking change. 13 | 14 | This can be mitigated a few ways, either restrict implied bounds to only the 15 | crate, make implied bounds be publicly exportable, or maybe some fancy stuff 16 | based on usage that I didn't totally understand. 17 | 18 | ## Specialization 19 | 20 | Not much backwards incompatibility so not very relevant to edition planning. 21 | 22 | There's talk of making it eventually opt-out by default, but it doesn't seem 23 | likely that this would happen short term, so specializable impls must be marked 24 | `default` initially. 25 | 26 | Also they may initially stabilize the `min_specialization` subset being used in 27 | the compiler right now which I think only allows specializing for concrete 28 | types, not for things like `T where T: Trait`. 29 | 30 | ## if let or exit function 31 | 32 | They talked about implementing an inverse fallible binding for making a binding 33 | or exiting early that might require a small backwards incompatible change that 34 | doesn't affect any known code. 35 | 36 | The main syntax proposal seems to be 37 | 38 | ```rust 39 | let Some(x) = y else { 40 | return Err(BrokenThingsAlert); 41 | } 42 | 43 | println!("{}", x); 44 | ``` 45 | 46 | This also ties into or patterns, they might be looking for ppl motivated to 47 | work on this 48 | 49 | ## Unsafe in Unsafe Function 50 | 51 | They're working on making the bodies of unsafe fns safe by default, but due to 52 | the size of the change they're considering breaking this up across multiple 53 | editions I think. 54 | 55 | They're definitely planning on handling this with `rustfix` but its unclear how 56 | well they can do this, so its unclear but it might be that in 2021 its only a 57 | warning if you use an unsafe expr in an unsafe fn without an unsafe block. 58 | 59 | ## Early return with error 60 | 61 | Assuming that a keyword is picked in time (presumably before october) the plan 62 | is to reserve that keyword as part of the next edition. 63 | 64 | ## Impl Trait 65 | 66 | Seems to be progressing nicely, there are some discrepancies between the RFC 67 | and the implementation that need to be reviewed. 68 | 69 | This will apparently help with async fns, tho not the ones with GATs, but niko 70 | seemed to think that will be done by 2021 as well maybeee ?? 71 | 72 | ## Implicit modules 73 | 74 | Explicit modules can be confusing and lead to confusing errors that arise due 75 | to lacking a `mod foo` statement, even for experienced users. However, last 76 | year we did hit some real challenges with removing them, both because of 77 | disturbing users' existing workflows and technical limitations associated with 78 | scanning directories on networked file systems and the like. 79 | 80 | Conclusion was that we're not really inclined to "re-open" this issue -- we did 81 | a lot of work on modules and we want to move onto other areas at the moment. 82 | However, as a simple step, we would be interested in adding a lint that warns 83 | about missing `mod foo` statements and improving error messages as a starting 84 | point (because the lint can be disabled, or disabled by default, that would 85 | address the problems around networked file systems). 86 | 87 | ## Crate visibility 88 | 89 | We held off on stabilizing `crate fn` because of concerns around a parser 90 | ambiguity. We'd like to revisit that, it seems like a relatively small change 91 | and it's still definitely a "nice to have". We do have to investigate the 92 | options for resolving the ambiguity, which had to do with types like `struct 93 | Foo(crate ::bar)`. (There is a listing of some of the options in the paper 94 | doc...) 95 | 96 | ## Type Ascription (and Named Arguments) 97 | 98 | They're particularly worried about not conflicting with future named arguments 99 | syntax, so it seems like they might deprecate some syntax to allow named args 100 | to use `=` as a separator so type ascription can safely use `:` 101 | -------------------------------------------------------------------------------- /design-meeting-minutes/2020-07-01-safe-transmute-typic.md: -------------------------------------------------------------------------------- 1 | # design meeting 2020-07-01 2 | 3 | * [Recording available](https://youtu.be/3aw-5Fcyo7s) 4 | * [Meeting proposal](https://github.com/rust-lang/lang-team/issues/26) 5 | * Starting from safe transmute but generalized to specialized traits that let you determine when types are laid out in particular ways and can be interconverted etc 6 | * Two main approaches 7 | * ZeroCopy -- not very granular 8 | * 'Typic' -- Expose type layout to the type system in a "perfect" way (or close to perfect) 9 | * Most of the time, the traits from ZeroCopy are enough, and it'd be nice to be able to ask simple questions like "can this be zeroed" 10 | * Probably want a combination. Use typic as the foundation but have simple traits exposed to users for common use cases. 11 | * Question: Can this handle endian-ness cleanly? 12 | * typic -- not presently 13 | * zerocopy -- sort of 14 | * this kind of amounts to inserting types from byteorder crate, which will do conversions to/from native endianness as you do your accesses 15 | * Is there a question for us to ponder/answer today? 16 | * John: I want to show how typic works 17 | * Ryan: I'm fairly convinced this functionality belongs in the stdlib. 18 | * Error messages are gnarly. 19 | * It's awfully unsafe and offers the ability to remove unsafe operations from library types. 20 | * Overall area is quite large, not quite clear exactly what are the smallest pieces we can start moving into stdlib, to ultimately get to a goal with a 1-line safe transmute? 21 | * Is expectation that moving some part of this to stdlib would benefit from compiler support? 22 | * Yes. 23 | * typic tries to solve an ambitious goal -- 24 | * deprecating `mem::transmute`, such that if you find yourself calling it, you are probably doing something fundamentally unsound 25 | * but realizing that vision requires global knowledge of types, which typic lacks 26 | * so long term, realizing typic would really require compiler support 27 | * compiler has that ground truth of what the layout looks like anyways, so it'd be nice to build on that 28 | * Josh: is there a clean obvious line like "if the compiler did this much, we could build on that in ecosystem" or is it necessarily the case that compiler/lib support wants to go in simultaneously? 29 | * We'll get to that. 30 | * Promising path might be: 31 | * Unsafe zerocopy traits with a marker attribute 32 | * Free to add an intelligent, automatic version, but until then libs can pick up some of the slack 33 | * Screen share time! 34 | * "As easy as 1..2..repr(C)" (not an actual quote, but should've been) 35 | * How complex do we want? 36 | * zerocopy is based around "can this be made to bytes". Combined with dynamic alignment checks, this can cover a lot of cases, but not as many as typic. This covers e.g.: 37 | * interconvering a `&[Point]` to `&[f32]`, for example (hmm, adjust length?) 38 | * Examples typic solves that don't fit into this category 39 | * showing that two types with padding are interconvertible because they have padding in the same places 40 | * can permit interconversion between enums, understanding the discriminant values and so forth 41 | * Some present shortcomings 42 | * typic doesn't understanding that `Option<&u32>` and `*const u32` are equivalent 43 | * public interface is fine for this 44 | * private perspective: sounds hard 45 | * If the high-level interface of this is sufficiently capable, then do you believe that some of the internal details would be easier given compiler assistance behind the scenes? 46 | * Yes. I see the future of typic being that the compiler exposes some kind of unstable intrinsic with a predicate (`can_transmute` that returns a boolean). 47 | * And a public facade implemented and based on that. 48 | * e.g., being able to do `where { can_transmute }` 49 | * Can in shorter time frame expose zerocopy traits like 50 | * `AsBytes` 51 | * `FromBytes` 52 | * `Unaligned` 53 | * we could move those traits to the standard library and annotate them with the marker attribute 54 | * stdlib can evolve how smart it is and until that time people can implement manually 55 | * carrying an options `O` type is essential 56 | * What would next step for this be? 57 | * Josh: This approach seems single, it would make sense to have a path for implementing a nightly only prototype in the compiler to demonstrate that this gets easier with compiler support. 58 | * John: Having a `can_transmute` const fn predicate would be useful, as it would allow us to test our implementations on compiler ground truth 59 | * Scott: How much do we want to do the whole from-bytes/to-bytes thing earlier? 60 | * Could be done in a library today with auto-traits? 61 | * Taylor: you need repr-C / padding checks? 62 | * Scott: `FromBytes` doesn't need padding, right, since you can overwrite padding with arbitrary values? 63 | * Josh: That sounds right 64 | * John: I think having `FromBytes` and friends in the core library without anything backing them up would be helpful 65 | * Niko: They do have to obey the coherence rules, right? 66 | * John: Crates already have to manage that because they use derive 67 | * Niko: I just meant stuff like `u8`, slices, references 68 | * Ryan: I have the mem-markers repo... 69 | * scottmcm: There is also "all bytes are valid and no padding" -- we could expose a trait that is implemented for such types -- those are the core constraints that a library might use to implement support for transmutes etc, but that becomes a marker trait with no methods at all. Up to some other library to make from-bytes... 70 | * John: At that point, the compiler needs to do some fairly in-depth reasoning at type-check time, so it's a small leap from there to just having the full safe transmute. 71 | * scottmcm: In other words, not that much harder to do "between arbitrary types" than this special case? 72 | * John: Right. 73 | * scottmcm: Maybe there is some kind of compile-time reflection? 74 | * typic doesn't expose the byte-level repr of type layouts. It is changed all the time. 75 | * Hard to envision infinitely into a future-proof way to represent a type layout. 76 | * Some questions to maybe follow up on: 77 | * What did those comments mean about needing a "global view" in the beginning? -- Niko 78 | 79 | -------------------------------------------------------------------------------- /design-meeting-minutes/2020-07-08-lang-team-path-to-membership.md: -------------------------------------------------------------------------------- 1 | # 2020.07.08 — Lang Team Path To Membership 2 | 3 | [Recording available](https://youtu.be/SeH-hZgDG1Y) 4 | 5 | - [Compiler-team meeting issue #32](https://github.com/rust-lang/lang-team/issues/32) 6 | - MCPs are revealing, imo, a liaison shortage, and our team has been steadily reducing in number, so we need to think about recruiting 7 | - Project group lead is a good start but it doesn’t demonstrate 8 | - ability to work on projects that are not your own passion 9 | - ability to work with others 10 | - Path to membership that doubles also as “expectations for a lang-team member” 11 | - Project group lead 12 | - Liaison 13 | - Participate regularly in meetings or in some fashion 14 | - What is the role of the liaison? 15 | - Should we expect neutrality, sort of like Manish with the [Facilitator blog post](http://- https://manishearth.github.io/blog/2019/02/04/rust-governance-scaling-empathy/)? 16 | - Do all groups need a liaison? 17 | - Most important typically mostly for controversial topics 18 | - Pre-requisite might be the number of participants 19 | - maybe like if the discussion is large enough, there should be a facilitator 20 | - What are the expectations for a lang-team member? Some subset of: 21 | - Lead project groups, where appropriate 22 | - Liaison for projects, where appropriate 23 | - Participate in triage meetings 24 | - Participate in design meetings 25 | - Respond to rfcbot fcp requests in a timely fashion 26 | - Participate constructively in, and help facilitate, RFC discussion, issues, PRs, and other GitHub-based discussions 27 | - Provide important technical points 28 | - Help to drive discussions towards common understanding 29 | - Understanding and documenting the positions and points being raised 30 | - Monitor and respond to communication in Zulip 31 | - Note that these expectations do not preclude taking vacations, or having periods where you’re excessively busy, as long as that’s well-communicated to the rest of the team. 32 | - Desire a certain sense of generality 33 | - Levels of lang-team membership? 34 | - What is the “core piece” of membership? 35 | - Is it checking off the RFC/FCP checklist? 36 | - this is certainly, in an operational sense, the *core* thing 37 | - Necessary but not sufficient, perhaps. We should expect participating in some subset of the things above as well. 38 | - Working backwards from box checking: 39 | - the critical part is having concerns, which requires knowledge, and then communicating that concern in a way that it can be resolved 40 | - Path to membership is to complete these things: 41 | - Lead one or more project groups 42 | - Liaison one or more project groups 43 | - Demonstrating capability to build consensus and encourage productive discussion 44 | - ideally, we’d be able to point to official summary comments and the like 45 | - If we said that there was a role of explicit facilitation, it’d be easier to identify those comments 46 | - we shouldn’t expect facilitators not to have opinions, may be true but also sometimes impossible 47 | - but you should still be able to produce summaries 48 | - Levels of membership 49 | - Is there a role like compiler team contributors that makes sense? 50 | - Maybe collecting liaisons etc? Is there any benefit to this? It’s not obvious what they have in common. 51 | - Might just be like “people who are liaison’ing, which is a really valuable contribution” 52 | - after N months of inactivity 53 | - Being able to ping for meetings is at least a useful 54 | - MCP quality of service 55 | - Can we have deadlines or other things 56 | - Some kind of regular ping might be helpful here 57 | - Zulip ping @T-Lang may help 58 | - Circling back: 59 | - Can we get consensus on the idea of non-lang-team liaisons and some consensus on the idea of an explicit path? 60 | - How do we feel about having project groups with no lang team members at all? 61 | - For things that are not “core efforts’, seems ok, but there are risks 62 | - Would be more upset to be declined if nobody is involved 63 | - Good idea to have clearer charter and expectations in these cases 64 | - We should select non-lang-team liaisons based on an expectation of good language design sense 65 | - Also, we would still expect that liaison person is someone we’ve had good experience with and who is committed to project, so that mitigates risk 66 | - Next steps: 67 | - Write this up in the form of documentation 68 | - Amend MCP RFC perhaps 69 | - If you have people you think might be good liaisons, bring up in t-lang/private Zulip stream 70 | 71 | 72 | -------------------------------------------------------------------------------- /design-meeting-minutes/2021-02-17-Increasing-Trust-in-Rust-Compiler.md: -------------------------------------------------------------------------------- 1 | # 2021-02-17: Increasing trust in rust compiler 2 | 3 | * [Watch the recording](https://youtu.be/o896qSpTigg) 4 | 5 | ## Goal 6 | 7 | Expore the answers to the questions: If we were to charter a group to explore "improving trust" in the Rust compiler... 8 | 9 | * What would be the first deliverables? 10 | * What components would we want to "specify" and why/how? 11 | * What are the *audience* for those deliverables? 12 | * How can we help folks follow along who need to understand the details? 13 | * What teams and/or folks would we want involved? 14 | 15 | ## Agenda 16 | 17 | * Discussion of goal-setting proposal circulated before 18 | * Q&A 19 | * Industry specific details 20 | * Discussion of needs around safety critical 21 | * Potential next steps 22 | 23 | ## Attending 24 | 25 | 26 | ## Notes 27 | 28 | * Introduction to attendants 29 | * Walking through the document: 30 | * Core focus: basing analysis on MIR, that's where the research projects are focused 31 | * Having access to traits, borrow checker is also important 32 | * Might also need a "contract language" in order to do verification 33 | * contracts like this can be really useful for language verification and fuzzing 34 | * Example of verification that is done using MIR? 35 | * MIR semantics are much simpler than Rust. Therefore, creating formal semantics from MIR makes sense, because it's so much easier. 36 | * Contract language is "in scope" "around" a lot of the things, but isn't the primary goal for this proposal 37 | * What kinds of properties might people want to prove? 38 | * e.g., proving specific postconditions? Or proving functional correctness? 39 | * Answer: not there yet, need specification for MIR first 40 | * Example question: can we possibly have undefined behavior? 41 | * Other extreme: is this bit-for-bit identical to the specification? 42 | * That requires a lot more human effort in practice to make a proof. 43 | * How stable does MIR have to be etc? 44 | * Strict stability: we specify MIR and it never changes. 45 | * Semver stability: we specify MIR but we tell you when it changes. 46 | * The latter is easier and good enough. 47 | * "We think it would be a boost to the language if MIR-as-core-spec was something we were handling" 48 | * We're looking for the "normative definition" that we can do compiler assurance on 49 | * Starting from the Rust source language is much more complex than trying to assure from MIR on down 50 | * MIR is a good middle ground 51 | * eventually want a contract between front end and MIR 52 | * and MIR and the back end 53 | * "More than willing to invest time/engineering to keeping up with MIR, but how to know that we're able to do it" 54 | * want to avoid subtle changes of semantics 55 | * Primarily interested in consuming MIR that was generated from the Rust compiler... 56 | * Is there also interest in producing MIR that was not produced by the Rust compiler? 57 | * Answer: Consuming output is the more important goal. 58 | * Being able to say "this version of the compiler produces MIR 12" and then having tools being able to verify that the tool expects MIR 12 too 59 | * Also want to connect Rust front end to different (non-LLVM-based) backends, MIR might be a useful intermediary there 60 | * Serialized MIR might be one way to go about this 61 | * Josh: We probably don't want to be able to take arbitrary MIR yet, because portions of MIR not generated by rustc are likely to be less well-exercised, and that's a surface area we may not want to expose 62 | * Use case: compiling down from Coq etc would be easier if it targeted MIR 63 | * But we might want to do "MIR-to-MIR" transformations 64 | * e.g., adding "ghost state" 65 | * Other concern: 66 | * There could be UB in Rust surface syntax that doesn't surface in MIR 67 | * This is worth keeping an eye on 68 | * How can we keep lang team and group in sync? 69 | * Having a clear roadmap etc 70 | * This story is not just about MIR, but also parts of the type system 71 | * What other static analysis results would you need access to? 72 | * e.g., Borrow checker / region inference? 73 | * Answer: it depends on who you talk to and what their needs are 74 | * Some folks want a "MIR that is to be borrow checked" 75 | * Does this mean "people might want to write their own borrow checker", or that you want to consume results of the Rust borrow checker? 76 | * Answer: we do want analysis results, also for performance reasons; being able to rule out potential aliases thanks to compiler analysis can dramaticaly improve the scalability 77 | * Others want "MIR" post-borrow-checking, post-monomorphization 78 | * Specifications: 79 | * How should we think about specifying the borrow checker? 80 | * Consider how many times we have changed it, e.g. NLL 81 | * Versioning may be part of the answer 82 | * Stacked borrows also aimed to define a definition of UB that is kind of maximally flexible 83 | * with the borrow checker as a conservative approximation on it 84 | * Next steps? 85 | * One outcome: find the group that will continue this conversation 86 | * 87 | 88 | -------------------------------------------------------------------------------- /design-meeting-minutes/2021-02-24-lints-and-editions.md: -------------------------------------------------------------------------------- 1 | --- 2 | tags: design-meeting 3 | --- 4 | 5 | # 2021-02-24: Lints and editions 6 | 7 | ## Links 8 | 9 | * [Proposed lint/error policy](https://hackmd.io/i1Ob4XS6TwuUv-rOVEoM4A) 10 | * [Lint categorizations and descriptions](https://hackmd.io/HETreGqPSRezlN109vgCnQ) 11 | 12 | ## Agenda 13 | 14 | * Overview general lint policy (15 minutes) 15 | * Key questions: 16 | * 17 | * Overview lints (30 minutes) 18 | * Per 19 | * Revisit general lint policy (15 minutes) 20 | 21 | ## General lint policy 22 | 23 | 24 | | name | Edition N | Edition N+1 | Migrations? | 25 | | --- | --- | --- | --- | 26 | | repurposed syntax | allow | new meaning | mandatory | 27 | | edition error | allow | error | mandatory | 28 | | soft deprecations | warn | warn | recommended | 29 | | hard deprecations | warn then deny | deny | mandatory | 30 | | bug fix | warn then error | warn then error | recommended | 31 | 32 | Niko's concerns 33 | 34 | * edition error: is there syntax we remove that is NOT deprecated? 35 | * hard deprecation: is there a reason that we would want deny in the new edition, and not error? 36 | * something we want people to be able to type but they have to opt-in with allow (versus some other mechanism)? 37 | * soft vs hard: 38 | * hard is for likely BUGS 39 | * not just a matter of "it'd be nice if this were better" but more like "some horrible problem" 40 | * Extreme danger of misuse or unsoundness. 41 | * Third-party tooling may wish to drop support for the pattern (and limit itself to the newer editions). 42 | 43 | ## Table 44 | 45 | | Lint | Current status | Proposed resolution | Bugs | Meeting consensus? | 46 | | --- | --- | --- | --- | --- | 47 | | BARE_TRAIT_OBJECTS | warn | soft deprecation
edition error | :heavy_check_mark: | 48 | | ELIDED_LIFETIMES_IN_PATHS | allow | no consensus | | 49 | | ELLIPSIS_INCLUSIVE_RANGE_PATTERNS | warn | soft deprecation
edition error | 50 | | EXPLICIT_OUTLIVES_REQUIREMENTS | allow | revisit after bugs are fixed | [#54630] | 51 | | UNUSED_EXTERN_CRATES | allow | not edition (though it take the edition into account) | 53964, 44294 | 52 | | UNREACHABLE_PUB | allow | defer, not edition | 53 | 54 | | MACRO_USE_EXTERN_CRATE | allow | decide as part of pub macro-rules | #52043 55 | | CLASHING_EXTERN_DECLARATIONS | allow | hard deprecation | #52043 | 56 | 57 | 58 | [#54630]: https://github.com/rust-lang/rust/issues/54630 59 | -------------------------------------------------------------------------------- /design-meeting-minutes/2021-04-14-Planning-Meeting.md: -------------------------------------------------------------------------------- 1 | # Planning meeting 2021-04-14 2 | 3 | ## Attending 4 | 5 | * Team: Niko, Josh, Felix, Scott, Taylor 6 | * Other: simulacrum, Amanieu, Esteban 7 | * Action item scribe: simulacrum 8 | * Minutes scribe: nikomatsakis 9 | * [Watch the recording](https://youtu.be/-V2zxC8YpnI) 10 | 11 | ## Design meeting candidates 12 | 13 | * Rust language "guiding principles" [lang-team#91](https://github.com/rust-lang/lang-team/issues/91) 14 | * nikomatsakis has been sketching guiding principles from async vision doc and they seem like decent principles for the language overall 15 | * not quite ready to schedule this this month 16 | * pnkfelix has related ["compiler team contributors" guiding principles](https://hackmd.io/TYGRjVIbSBmxpbcfDzll-w) 17 | * Discuss the amount of oversight that lang should have for lints [lang-team#72](https://github.com/rust-lang/lang-team/issues/72) 18 | * needs a proposal before we decide whether to have a meeting 19 | * it may be that no meeting is required 20 | * Discuss the possibility of denying bare_trait_objects in 2021 edition [lang-team#65](https://github.com/rust-lang/lang-team/issues/65) 21 | * action item: Mark to close this 22 | * PR is https://github.com/rust-lang/rust/pull/83213#issuecomment-812120957 23 | * Just got its third checkbox; now in FCP merge. 24 | * Ongoing discussion about `Drop` and `Pin<&mut self>` for 2021 edition 25 | * 2021 planning ruled this out because it didn't meet the "accepted RFC" deadline 26 | * not scheduled this round, there is ongoing discussion on Zulip 27 | * should move that discussion somewhere else on Zulip instead of "Edition 2021" stream 28 | * New ABI: "wasm" [lang-team#90](https://github.com/rust-lang/lang-team/issues/90) 29 | * alexcrichton is working towards wasm interop 30 | * the wasm ABI being proposed here is the proposal that should work across runtimes 31 | * lang team question: do we want to have an ABI named wasm and how does it differ from C ABI? 32 | * may also touch on bigger questions like how wasm could integrate into rust language design 33 | * doc expectations: 34 | * Details about the ABI, but only if they raise complex language questions 35 | * Specific Questions: Why is this not just the C ABI for the WASM targets? 36 | * Understanding the roadmap and where lang design changes may be needed 37 | * Generators planning [lang-team#92](https://github.com/rust-lang/lang-team/issues/92) 38 | * Estaban wants to see driven to completion, ideally this year 39 | * Related to async vision doc effort 40 | * doc expectations: 41 | * Sketch and present a plan for how to settle the open questions 42 | * Strawperson for a plan with details to help gauge where people fall 43 | 44 | ### Dates 45 | 46 | * [ ] April 21: [lang-team#90](https://github.com/rust-lang/lang-team/issues/90) 47 | * [ ] April 28: [lang-team#92](https://github.com/rust-lang/lang-team/issues/92) 48 | * [ ] May 5 <-- next planning meeting 49 | * Doc and agenda available the day before the meeting 50 | 51 | ## Updates 52 | 53 | ### Questions to consider for updates 54 | 55 | * What are recent topics of discussion? 56 | * Any exciting developments since the last check-in? 57 | * Any points where the group is stuck and the lang-team could weigh in? 58 | * Any potential design meeting topics? 59 | * Any other concerns? 60 | 61 | ## Updates from active groups and projects 62 | 63 | * [Project board](https://github.com/rust-lang/lang-team/projects/2) 64 | * Active projects (design phase) 65 | * [Const evaluation](https://github.com/rust-lang/lang-team/issues/22) 66 | * [Async foundation](https://github.com/rust-lang/lang-team/issues/33) 67 | * [Const generics](https://github.com/rust-lang/lang-team/issues/51) 68 | * [Deref Patterns](https://github.com/rust-lang/lang-team/issues/88) 69 | * [Denying semicolons in expression macro bodies](https://github.com/rust-lang/rust/issues/79813) 70 | * [Safe transmute](https://github.com/rust-lang/lang-team/issues/21) 71 | * Active projects (implementation) 72 | * [Tracking Issue for RFC 3086: macro metavariable expressions](https://github.com/rust-lang/rust/issues/83527) 73 | * [RFC 2229](https://github.com/rust-lang/lang-team/issues/50) 74 | * [Never type stabilization](https://github.com/rust-lang/lang-team/issues/60#issuecomment-814509681) 75 | * I'm currently using Infallible for `TryV2` (https://github.com/rust-lang/rust/pull/84092/files#diff-61f98b185ed55c4151035e7b82e7ac945377f8bfcb5133f16f9a595838e01a10R1653), but it sure would be nice to use `!`. 76 | * [FFI Unwind](https://github.com/rust-lang/lang-team/issues/19) 77 | * Active projects (evaluation) 78 | * [Inline assembly](https://github.com/rust-lang/rust/issues/72016) 79 | * [Instruction set attribute](https://github.com/rust-lang/rust/issues/74727) 80 | * Active projects (stabilization) 81 | * [Stabilize pat2015 but leave :pat2021 gated](https://github.com/rust-lang/rust/pull/83386) 82 | * [Tracking issue for X.., ..X, and ..=X](https://github.com/rust-lang/rust/issues/67264) 83 | -------------------------------------------------------------------------------- /design-meeting-minutes/2021-06-02-planning-meeting.md: -------------------------------------------------------------------------------- 1 | # Planning meeting 2021-06-01 2 | 3 | Attendance: 4 | 5 | * Team: Niko, Scott, Josh, Taylor, Felix 6 | * Others: simulacrum, Mara 7 | 8 | ## Design meeting proposals 9 | 10 | * [Design note catch up #95][] 11 | * [Structural equality #94][] 12 | * Status updates from projects 13 | * Lang team process proposal 14 | 15 | [Design note catch up #95]: https://github.com/rust-lang/lang-team/issues/95 16 | 17 | [Structural equality #94]: https://github.com/rust-lang/lang-team/issues/94 18 | 19 | ## Calendar this week 20 | 21 | ### Availability 22 | 23 | * Today: Design note catch up 24 | * June 9 -- Niko, Felix not available 25 | * June 16 -- Structural equality 26 | * June 23 -- Possible: Atomic follow-up 27 | * June 30 -- Lang team process proposal 28 | 29 | ## Design note notes 30 | 31 | Goal: 32 | 33 | * Role of a design note is to document the design space that is explored and tradeoffs uncover 34 | * Consensus does not represent lang team agreement to accept the feature, just that the document is generally accurate 35 | * Someone from lang team was going to own and merge when they felt it was ready, running it by the appropriate stakeholders 36 | 37 | ### "Initial draft of copy ergonomics design note" lang-team#62 38 | 39 | **Link:** https://github.com/rust-lang/lang-team/pull/62 40 | 41 | * Niko for Mara: range discussion from libs team? 42 | * Niko: could reference match ref bindings interactions 43 | * Scott: feel pretty good, looks like there've been a number of updates 44 | * Josh: added a comment with a suggested change 45 | * Felix: I don't know if it is sound for `MaybeUninit` to be copy? 46 | * cramertj: When `T: Copy`, right? 47 | * scott: it's safe to copy, it's the "assume uninit" that is not 48 | * cramertj: today, copy is the only way to know whether something can be memcpy'd, but I think we don't necessarily want that to be implicitly copyable. 49 | * Some types should be memcpy'able but not necessarily implicitly copyable 50 | * Others could plausibly be "implicitly cloneable" (rc, arc), even though they are not memcpy. 51 | * Mem copy may be important for specialization. 52 | * Mark to add notes 53 | * may want to link to https://github.com/rust-lang/rfcs/pull/2111 54 | * Assign to pnkfelix 55 | 56 | ### "Autoref/autoderef for operators" lang-team#63 57 | 58 | **Link:** https://github.com/rust-lang/lang-team/pull/63 59 | 60 | * Niko: it would be nice to have more canonical examples, what are the pain points? 61 | * link https://github.com/rust-lang/rfcs/pull/2111 in this note 62 | * Mark: String + &str, String + str etc 63 | * depends impls can be fn(self, Other) or fn(&self, &Other) 64 | * Felix: do we expect to be able to avoid the inference breakage if we add this feature? 65 | * Josh: I think part of the point was to have the compiler be able to figure out which impl it needs better 66 | * Mark: if you know that these impls are all equivalent might mean you can be more intelligent 67 | * implications of adding in generic code (e.g., `T` + `&T`) 68 | * Niko: examples of breakage are useful 69 | * Scott: adding `Add` to `u32` 70 | * `0 + s.parse().unwrap()`, plausibly 71 | * Mark to add notes 72 | * Review: scottmcm 73 | 74 | ### "Auto trait design note" lang-team#69 75 | 76 | **Link:** https://github.com/rust-lang/lang-team/pull/69 77 | 78 | * Scott: Covers semver and reflects the conversation 79 | * Niko: I'd be up to merge as is, and maybe add some notes later on related topics 80 | * Niko to own merging, Mark to quickly add forgotten auto traits 81 | 82 | ### "Add design notes for function-type `Default` implementation discussion" lang-team#71 83 | 84 | **Link:** https://github.com/rust-lang/lang-team/pull/71 85 | 86 | * Josh: Feels sort of like a rebuttal 87 | * Niko: seemed to cover all the points in a satisfactory way 88 | * cramertj: Not the use of the word thunk that I'm familiar with. 89 | * Felix: me too 90 | * cramertj: I'm accustomed to a "thunk" being a function that you call that produces more steps 91 | * Josh: I think I can see how the term "thunk" would apply 92 | * scottmcm: Trampoline? 93 | * cramertj: not very clear to me how you would call `add_one_thunk`, given that you can't name the function type? 94 | * niko: possibly with a named impl trait 95 | * josh/pnkfelix: I'd like to see definition plus usage 96 | * cramertj: wouldn't the use cases here be covered by a fn trait that doesn't take self? 97 | * niko/scott: fnstatic is in the doc 98 | * mark: I think that, unlike the other design notes, this feels more like it's a summary of how you could achieve the feature 99 | * niko: I'm good with that I just think it needs a clearer title 100 | * josh: it feels like "we want to add this thing, here' show to do it" 101 | * niko: I'm ok with that, but I think it should just be "if we want to add this thing..." 102 | * mark: I think it'd be useful to have more examples of how this might look 103 | * in particular how do you use this thing and why 104 | * pnkfelix: what about generators? of course, if there are no upvars... 105 | * ...at least for opt-in trait impls, you might want that for generators, right? 106 | * niko: that sounds like a consideration to add 107 | * scottmcm: I don't know if this needs to be in the doc, but all the questions around specialization makes some of the leakage things different, but maybe that's not specific to this note in particular, and is just something for the stabilizing-specialization conversation. 108 | * Niko to follow up, suggest and/or make a few minor edits, then merge 109 | 110 | ### "Add draft of variadic notes" lang-team#76 111 | 112 | **Link:** https://github.com/rust-lang/lang-team/pull/76 113 | 114 | * cramertj: to follow up -------------------------------------------------------------------------------- /design-meeting-minutes/2021-09-01-Planning-meeting.md: -------------------------------------------------------------------------------- 1 | --- 2 | tags: planning-meeting 3 | --- 4 | 5 | # Planning meeting 2021-09-01 6 | 7 | ## Agenda 8 | 9 | * Go over the active initiative list 10 | * Design meeting scheduling 11 | 12 | ## Active initiative list 13 | 14 | - Tomorrow topic for planning meeting 15 | - Finalize list of existing initiatives 16 | - Select liaisons 17 | - Discuss how to handle random tracking issues 18 | - Niko created a [repository template](https://github.com/rust-lang/initiative-template) and instantiated various repos with it (linked in the doc) 19 | - [Draft initiative list](https://hackmd.io/zAqZPQt0SqWW7IWwbuLwyg) -- missing things? 20 | 21 | ## Upcoming meetings 22 | 23 | ### Design meetings 24 | 25 | * Sep 8 -- (Niko only semi-available) 26 | * Sep 15 -- (Niko only semi-available) 27 | * Sep 22 -- GATs [lang-team#115](https://github.com/rust-lang/lang-team/issues/115) 28 | * Sep 29 -- (reserved for last minute Rust 2021 stuff) 29 | 30 | ### Other meeting notes 31 | 32 | * Sep 14 -- RustConf (cancel triage meeting) 33 | -------------------------------------------------------------------------------- /design-meeting-minutes/2021-10-20-dyn-upcast-and-safety.md: -------------------------------------------------------------------------------- 1 | # Design meeting 2021-10-20: Dyn upcasting coercion safety 2 | 3 | ## Source document 4 | 5 | https://rust-lang.github.io/dyn-upcasting-coercion-initiative/design-discussions/upcast-safety.html 6 | 7 | ## Scenario 8 | 9 | * Casting `*dyn Foo` to `*dyn Bar` requires adjusting the vtable from a vtable for `Foo` to one for `Bar` 10 | * For raw pointers, the metadata can be supplied by the user with `from_raw_parts` 11 | * If that metadata is incorrect, this could cause UB: 12 | * our current vtable format requires loads, and the pointers may not be valid 13 | * a flat vtable layout could give rise to out-of-bounds loads 14 | 15 | Example: 16 | 17 | ```rust 18 | trait Foo: Bar { 19 | } 20 | 21 | trait Bar { 22 | 23 | } 24 | 25 | fn test(x: *const dyn Foo) { 26 | // Performing this upcast requires adjusting the vtable 27 | // from a `Foo` vtable to a `Bar` vtable. Given the current 28 | // layout, this may involve loading from memory. 29 | // 30 | // But `x` is a raw pointer: do we have any reason to assume 31 | // that the metadata for `x` is valid? 32 | let y: *const dyn Bar = x; 33 | } 34 | 35 | fn bad_actor() { 36 | let x: *const dyn Foo = from_raw_parts(ptr::null(), /*garbage*/); 37 | test(x); // crash 38 | } 39 | ``` 40 | 41 | So, clearly unsafety is needed, but where? Whose fault is the crash above? 42 | 43 | Note that, today, [from_raw_parts](https://doc.rust-lang.org/std/ptr/fn.from_raw_parts.html) is safe. It does however require a valid `Metadata` argument, which implies a correct vtable. 44 | 45 | ## Option 1: `*const dyn Foo` metadata must always be valid 46 | 47 | * Implies: 48 | * It is unsafe to create a `*const dyn Foo`. 49 | * Interestingly, from_raw_parts requires a valid metadata argument, so it can still be safe. The unsafety moves to transmuting and synthesizing the metadata somehow, which already requires unsafe. 50 | * The other source of unsafety is `transmute`. It would be UB to transmute something to `*const dyn Foo` without valid metadata. 51 | * Also implies: 52 | * There is no obvious way to have a "null pointer" for `*const dyn Foo` 53 | * Without a data pointer, you don't know what its metadata should be 54 | * We could plausibly have a "sentinel" vtable for null, or have some way to synthesize a vtable for a given trait that is "structurally valid" but has null pointers for every method. 55 | * Note that currently `ptr::null` requires `T: Sized` 56 | 57 | ## Option 2: Raw pointer upcast is only allowed with valid metadata 58 | 59 | * Implies: 60 | * It is unsafe to perform an "unsizing upcast" to `*const dyn Bar` 61 | * It is also a rather special rule, since ordinarily upcasts are managed by the [`CoerceUnsized`](https://doc.rust-lang.org/std/ops/trait.CoerceUnsized.html) trait, and we don't have a mechanism to make trait matching unsafe depending on which *impls are used* (i.e., [this impl](https://doc.rust-lang.org/core/ops/trait.CoerceUnsized.html#impl-CoerceUnsized%3C*const%20U%3E-2) would be unsafe to use, which is not a concept the trait system has right now). 62 | * But then upcasting is already a builtin operation. So we can totally have a rule that says "when doing an unsize coercion, look at source/target types and apply this ad-hoc safety rule". 63 | 64 | The following code would no longer compile (is there a version of this code that doesn't require a feature gate?): 65 | 66 | ```rust 67 | #![feature(unsize)] 68 | 69 | use std::marker::Unsize; 70 | 71 | fn unsize(v: *mut A) -> *mut B 72 | where 73 | B: ?Sized, 74 | A: Unsize, 75 | { 76 | v 77 | } 78 | ``` 79 | 80 | ## Other options? 81 | 82 | We could potentially alter the vtable format to avoid needing a load but that is an undesirable limitation. 83 | 84 | ## Recommendation 85 | 86 | Option 1: Require metadata for `*const` wide pointers to be valid 87 | 88 | ### Just have unsafe upcast? 89 | 90 | * cramertj: I think there's another option: make raw pointer upcasting unsafe. Isn't that the place where the issue actually occurs? 91 | 92 | ### Special-case NULL? 93 | 94 | * Josh Triplett: I don't know if this would be an excessive performance hit, but could we special-case the NULL pointer, return another NULL pointer in that case, and *otherwise* look at the metadata? This would effectively treat NULL as None for a raw pointer, and the upcast operation as a `.map`. 95 | * Related: this assumes it's OK for a NULL pointer to not have valid metadata. 96 | 97 | ### Why is it unsafe to create *const dyn Foo if it requires valid metadata? 98 | 99 | * Mark: In particular, it seems like if you're creating *from* e.g. `&dyn Foo`, this should be safe, right? 100 | * cramertj: did this perhaps just mean "from an integer or cast from other raw pointer"? I agree with Mark that `&dyn Foo -> *const dyn Foo` seems like it should be safe no matter what choice we make. 101 | 102 | ### Q: Why is `fn from_raw_parts` not an unsafe fn? 103 | 104 | * pnkfelix: is there any chance we could justify the breaking change of making it an `unsafe fn`? 105 | 106 | ### Q: Do we need raw pointer upcasting? 107 | 108 | * Mark: Can we get away with just supporting upcasting for non-raw pointers, and then we "skip" this question? This is similar to Taylor's unsafe upcast, but is in some sense even simpler (and maybe in practice equivalent, presuming that the guarantees on upcast are equivalent to "needs to be safe to convert into &/&mut dyn temporarily"?). 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | -------------------------------------------------------------------------------- /design-meeting-minutes/2021-12-01-Planning-Meeting.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Triage meeting 2021-12-07 3 | tags: triage-meeting 4 | --- 5 | 6 | # T-lang meeting agenda 7 | 8 | * Meeting date: 2021-12-07 9 | 10 | ## Attendance 11 | 12 | * Team members: nikomatsakis 13 | * Others: Mark, Lokathor 14 | 15 | ## Meeting roles 16 | 17 | * Action item scribe: Mark 18 | * Note-taker: 19 | 20 | ## Scheduled meetings 21 | 22 | - December 8 -- Unstable feature backlog bonanza 23 | - December 15 -- lang-team#128 check-in 24 | - December 22 -- Either feature discussion from an initiative, or else backlog bonanza, to be decided on or by Dec 15 25 | - Let's skip December 29 (mid-holiday for many) 26 | 27 | ## Announcements or custom items 28 | 29 | (Meeting attendees, feel free to add items here!) 30 | 31 | ## Action item review 32 | 33 | * [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A) 34 | 35 | ## Pending lang team project proposals 36 | ### "negative impls integrated into coherence" lang-team#96 37 | 38 | **Link:** https://github.com/rust-lang/lang-team/issues/96 39 | 40 | ### "Deprecate target_vendor " lang-team#102 41 | 42 | **Link:** https://github.com/rust-lang/lang-team/issues/102 43 | 44 | ### "Async fundamentals initiative" lang-team#116 45 | 46 | **Link:** https://github.com/rust-lang/lang-team/issues/116 47 | 48 | ### "Attribute for trusted external static declarations" lang-team#118 49 | 50 | **Link:** https://github.com/rust-lang/lang-team/issues/118 51 | 52 | ### "Prototype Sync & Async Iterator Items (Minimal generators)" lang-team#121 53 | 54 | **Link:** https://github.com/rust-lang/lang-team/issues/121 55 | 56 | ### "Support platforms with size_t != uintptr_t" lang-team#125 57 | 58 | **Link:** https://github.com/rust-lang/lang-team/issues/125 59 | 60 | ### "Positional Associated Types" lang-team#126 61 | 62 | **Link:** https://github.com/rust-lang/lang-team/issues/126 63 | 64 | ### "Heap allocations in constants" lang-team#129 65 | 66 | **Link:** https://github.com/rust-lang/lang-team/issues/129 67 | 68 | 69 | 70 | ## PRs on the lang-team repo 71 | 72 | None. 73 | 74 | 75 | 76 | 77 | ## RFCs waiting to be merged 78 | ### "Static async fn in traits" rfcs#3185 79 | 80 | **Link:** https://github.com/rust-lang/rfcs/pull/3185 81 | 82 | 83 | 84 | ## Proposed FCPs 85 | 86 | **Check your boxes!** 87 | ### "Change location of where clause on GATs" rust#90076 88 | 89 | **Link:** https://github.com/rust-lang/rust/pull/90076 90 | 91 | ### "Relax priv-in-pub lint on generic bounds and where clauses of trait impls." rust#90586 92 | 93 | **Link:** https://github.com/rust-lang/rust/pull/90586 94 | 95 | 96 | 97 | ## Active FCPs 98 | ### "Stabilise `feature(const_generics_defaults)`" rust#90207 99 | 100 | **Link:** https://github.com/rust-lang/rust/pull/90207 101 | 102 | ### "negative impls integrated into coherence" lang-team#96 103 | 104 | **Link:** https://github.com/rust-lang/lang-team/issues/96 105 | 106 | ### "Positional Associated Types" lang-team#126 107 | 108 | **Link:** https://github.com/rust-lang/lang-team/issues/126 109 | 110 | 111 | 112 | ## P-critical issues 113 | 114 | None. 115 | 116 | 117 | 118 | 119 | ## Nominated RFCs, PRs and issues 120 | ### "Simple postfix macros" rfcs#2442 121 | 122 | **Link:** https://github.com/rust-lang/rfcs/pull/2442 123 | 124 | ### "Tracking issue for RFC 2115: In-band lifetime bindings" rust#44524 125 | 126 | **Link:** https://github.com/rust-lang/rust/issues/44524 127 | 128 | ### "Make specifying repr optional for fieldless enums" rust#88203 129 | 130 | **Link:** https://github.com/rust-lang/rust/pull/88203 131 | 132 | ### "Relax priv-in-pub lint on generic bounds and where clauses of trait impls." rust#90586 133 | 134 | **Link:** https://github.com/rust-lang/rust/pull/90586 135 | 136 | ### "remove pref_align_of intrinsic" rust#90877 137 | 138 | **Link:** https://github.com/rust-lang/rust/pull/90877 139 | 140 | ### "Allow using $:literal containing integer to index into a tuple" rust#91166 141 | 142 | **Link:** https://github.com/rust-lang/rust/pull/91166 143 | 144 | ### "New declarative macros, functions and fields not being recognized" rust#91249 145 | 146 | **Link:** https://github.com/rust-lang/rust/issues/91249 147 | 148 | ### "Unreachable code is not borrow-checked" rust#91377 149 | 150 | **Link:** https://github.com/rust-lang/rust/issues/91377 151 | 152 | ### "Mark defaulted `PartialEq`/`PartialOrd` methods as const" rust#91439 153 | 154 | **Link:** https://github.com/rust-lang/rust/pull/91439 155 | 156 | 157 | -------------------------------------------------------------------------------- /design-meeting-minutes/2022-03-02-planning-meeting.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Planning meeting 2022-03-02 3 | tags: planning-meeting 4 | --- 5 | 6 | # T-lang planning meeting agenda 7 | 8 | * Meeting date: 2022-03-02 9 | 10 | ## Attendance 11 | 12 | * Team members: nikomatsakis, Felix, Josh, Scott 13 | * Others: simulacrum, Jane, lcnr, Mara, Jakob 14 | 15 | ## Meeting roles 16 | 17 | * Action item scribe: 18 | * Note-taker: 19 | 20 | ## Annoucements 21 | 22 | * Niko + Josh getting close to a lang roadmap draft 23 | * [draft](https://hackmd.io/JGhj3CFJSmuDvpiPxbWaTQ) 24 | * Desire to incorporate libs work into this roadmap as well 25 | * Niko to attend ETAPS 2022 in Munich for https://sites.google.com/view/rustverify2022/home 26 | 27 | ## Availability 28 | 29 | * Mar 9: pnkfelix not available 30 | * Mar 16 31 | * Mar 23 32 | * Mar 30 33 | 34 | ## Proposed meetings 35 | 36 | - "Non-terminal divergence between parser and macro matcher " [lang-team#111](https://github.com/rust-lang/lang-team/issues/111) 37 | - "Lint policy" [lang-team#132](https://github.com/rust-lang/lang-team/issues/132) 38 | - nikomatsakis would like to see progress but doesn't feel ready to do the prep work 39 | - we have notes from before that we need to find first 40 | - https://hackmd.io/7YycPi5ORhiXbualfhaQRw -- Firefox AwesomeBar FTW! 41 | - "Plan for enum discrim, repr, and casting" [lang-team#134](https://github.com/rust-lang/lang-team/issues/134) 42 | - jswrenn was chasing this but he's busy with other things 43 | - "Astrologic chart (aka roadmap)" [lang-team#140](https://github.com/rust-lang/lang-team/issues/140) 44 | - scheduled for Mar 9 45 | - "RPITIDT" -- return position impl trait in dyn trait 46 | - scheduled for Mar 23 47 | - Backlog Bonanza! 48 | 49 | ### Plan 50 | 51 | * Mar 9: Roadmap [lang-team#140](https://github.com/rust-lang/lang-team/issues/140) 52 | * Do async work in advance, and then incorporate feedback afterwards and publish. 53 | * Mar 16: Backlog Bonanza! 54 | * Mar 23: RPITIDT [lang-team#144](https://github.com/rust-lang/lang-team/issues/144) 55 | * Mar 30: Lint policy [lang-team#132](https://github.com/rust-lang/lang-team/issues/132) 56 | * pnkfelix to write initial draft 57 | 58 | ### Closed during meeting 59 | 60 | - ""things other teams want"" [lang-team#130](https://github.com/rust-lang/lang-team/issues/130) 61 | - We should reach out to other teams, and only schedule this if a team has enough to make a meeting worthwhile. 62 | - "A path towards stable generic const expressions" [lang-team#138](https://github.com/rust-lang/lang-team/issues/138) 63 | - lcnr: this probably doesn't make too much sense atm, currently taking a step back wrt const generics so there isn't anything there rn. 64 | - nikomatsakis: should we close, lcnr? 65 | - jup, will do 66 | - "impl trait overview" [lang-team#142](https://github.com/rust-lang/lang-team/issues/142) 67 | 68 | ## Pending lang team project proposals 69 | 70 | Let's see if we can figure out what to do with these! 71 | 72 | ### Proposed changes: 73 | 74 | - Can we sort these? 75 | - E.g. by stage 76 | - maybe print date 77 | - What do we do when it is accepted 78 | - Open a tracking issue-- 79 | - on a repo if it has one 80 | - else on lang-team repo 81 | - tagged as T-lang C-initiative 82 | - add it to [this project board](https://github.com/orgs/rust-lang/projects/16/) 83 | - Policy for when to move out of proposal stage 84 | - If there is a second, it can move forward, don't need to reach consensus 85 | - But we should log concerns and liaison (or owner) should document some plan for how they'll be addressed 86 | - run that by the person who raised concern and get feedback 87 | - Can we make a better policy? 88 | - tag it with something after 1 month, give it 2 more weeks, then label again 89 | 90 | ### "Deprecate target_vendor" lang-team#102 91 | 92 | **Link:** https://github.com/rust-lang/lang-team/issues/102 93 | 94 | * scottmcm to second this 95 | 96 | ### "Async fundamentals initiative" lang-team#116 97 | 98 | **Link:** https://github.com/rust-lang/lang-team/issues/116 99 | 100 | * wanted a liaison 101 | * maybe close and rename to async fn in traits 102 | 103 | ### "Attribute for trusted external static declarations" lang-team#118 104 | 105 | **Link:** https://github.com/rust-lang/lang-team/issues/118 106 | 107 | * niko has seconded it 108 | 109 | ### "Support platforms with size_t != uintptr_t" lang-team#125 110 | 111 | **Link:** https://github.com/rust-lang/lang-team/issues/125 112 | 113 | * Concern: 114 | * Although the text of this proposal indicates that we should prepare an assessment, the name of the initiative ("support platforms...") suggests a conclusion. 115 | * It feels like a `rustbot second` would be endorsing that we should support such platforms; it's not clear if it makes sense for someone who believes we shouldn't support such platforms to second this proposal 116 | 117 | ### "Positional Associated Types" lang-team#126 118 | 119 | **Link:** https://github.com/rust-lang/lang-team/issues/126 120 | 121 | * can be approved but should document plan for how we will address usability 122 | * "we will meet with researchers to develop experiments" 123 | 124 | ### "Heap allocations in constants" lang-team#129 125 | 126 | **Link:** https://github.com/rust-lang/lang-team/issues/129 127 | 128 | -> niko proposes to close 129 | 130 | ### "Interoperability With C++ Destruction Order" lang-team#135 131 | 132 | **Link:** https://github.com/rust-lang/lang-team/issues/135 133 | 134 | ### "inner crates, aka multiple crates per file" lang-team#139 135 | 136 | **Link:** https://github.com/rust-lang/lang-team/issues/139 137 | 138 | ### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143 139 | 140 | **Link:** https://github.com/rust-lang/lang-team/issues/143 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | -------------------------------------------------------------------------------- /mermaid-init.js: -------------------------------------------------------------------------------- 1 | mermaid.initialize({startOnLoad:true}); 2 | -------------------------------------------------------------------------------- /minutes/2019-03-14.md: -------------------------------------------------------------------------------- 1 | # 2019.03.14 2 | 3 | These are the "minutes" from the meeting itself. You can view the 4 | [accompanying video on YouTube](https://youtu.be/atRKeoWbfi0). 5 | 6 | # Triage 7 | [x] [S-blocked-on-team issues](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AS-waiting-on-team) [(EMPTY)](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AS-waiting-on-team) 8 | [x] [Beta nominations](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3Abeta-nominated+label%3AT-lang) [(EMPTY)](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3Abeta-nominated+label%3AT-lang) 9 | [x] [P-high issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AP-high+label%3AT-lang) [(EMPTY)](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AP-high+label%3AT-lang) 10 | [ ] [Nominated PRs](https://github.com/rust-lang/rust/pulls?q=is%3Aopen+is%3Apr+label%3AI-nominated+label%3AT-lang) 11 | [ ] https://github.com/rust-lang/rust/pull/58739 12 | - We do not presently have a good way to model the current 2PB behavior 13 | - So the PR proposes a conservative static check 14 | - Case in question 15 | - `let p = &x;` // pre-existing borrow 16 | - `x.push(*p)` // `x` is mutable borrowed here, so can’t use `p` w/o changes 17 | - Levels 18 | - No 2PB 19 | - “basic stacked borrows” 20 | - Restricted 2PB (this PR) 21 | - “small diff” from the previous 22 | - disallows case in question 23 | - Full 2PB (present stable) 24 | - represents a **big change** from the previous 25 | - not sure how to handle this yet: 26 | - very permissive rules, with few optimizations 27 | - complex rules, with more optimizations but more expensive dynamic checks 28 | - Proposal (this one) 29 | - Treat this as a bug in rustc, more powerful than we intended 30 | - Introduce a future-compatibility warning for this case 31 | - this would add be added to an existing set of warnings 32 | - [Regressions have been tested:](https://github.com/rust-lang/rust/pull/58739#issuecomment-470230949) 33 | - 1 duplicate between github and crates.io (elba) 34 | - 3 root regressions of crates.io crates 35 | - 1 crates.io crate with reverse dependencies (by the same author) 36 | - 13 github only crates 37 | - Alternative (reject PR) 38 | - Treat this as a bug in the model 39 | - But we don’t know whether a model exists that satisfies the following criteria: 40 | - gives room for 2PB 41 | - permits the optimizations we want 42 | - is comprehensible to humans 43 | - Perhaps effect might be limited to 2PB 44 | - Observations 45 | - important to buy us time, getting a model is an important point 46 | - crater breakage is “tip of the iceberg” 47 | - existing code demonstrates that people try to write this 48 | - reality is that over time we fix bugs, and impose semantics 49 | - so we do warning transitions in any case 50 | - reality is that there are other sets of changes that cause breakage 51 | - e.g., adding `AsRef` impls and other inference breakage 52 | - there was a meeting that we planned to treat it as a bug 53 | - Proposal 54 | - Issue a Future Compatibility lint with the issue + lint 55 | - Phrase the text of the message carefully 56 | - Retrospective + plans to prevent this from happening again 57 | [ ] https://github.com/rust-lang/rust/pull/59114 58 | [x] [Nominated issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AI-nominated+label%3AT-lang+) 59 | [ ] [Nominated RFCs](https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AI-nominated+label%3AT-lang) 60 | [ ] https://github.com/rust-lang/rfcs/pull/2580 61 | [ ] https://github.com/rust-lang/rfcs/pull/2480 62 | [ ] [Unassigned RFCs](https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+no%3Aassignee+label%3AT-lang) 63 | 64 | 65 | # Unsafe code guidelines 66 | 67 | [Link to the writeup](https://github.com/rust-lang/lang-team/blob/master/working-groups/unsafe-code-guidelines/notes/2019-03-14.md) 68 | 69 | 70 | ## RFCs and what form it should take 71 | 72 | @centril: many RFCs seems more feasible than one 73 | 74 | - allows more detail-oriented and focused discussion 75 | - e.g. RFC for tuple representation 76 | 77 | **Proposal:** 78 | 79 | - Two interlinked outputs 80 | - Reference 81 | - Justification, drawbacks, and other considerations 82 | - (pros & cons, motivation, etc…) 83 | 84 | 85 | ## Language features 86 | - Identify the needs and try to keep them written 87 | 88 | 89 | ## Dynamic checking 90 | - Core principle: want to ensure that there is a nice way to run dynamically testing 91 | - Useful for programmers, but also researchers 92 | - lets you do verification, though efficiency matters less there 93 | - Currently using miri 94 | - this could be considered an artifact for us to stabilize 95 | - Areas of concern? 96 | - Recursive verification of validity checks could be much more expensive 97 | - we could make this configurable, but we would lose some precision 98 | - How deep are our references? Finding out may guide decision 99 | - Seeing how much code breaks when using deep references vs shallow might be interested data — nikomatsakis 100 | - Stacked borrows has to do a lot of checks 101 | - We should clearly identify where what miri checks diverges from the spec 102 | - and, in each case, have a good argument for why that is 103 | 104 | 105 | ## “Breaking” changes 106 | - didn’t get to this! 107 | ## Next area to focus 108 | - given 109 | ## Tuple layout (cramertj has concerns =) 110 | [ ] @Nicholas M to open an issue and ping Taylor 111 | 112 | 113 | -------------------------------------------------------------------------------- /minutes/2019-04-18.md: -------------------------------------------------------------------------------- 1 | [Video available here](https://youtu.be/MenZTdSzFVA) 2 | 3 | [Dropbox paper document available here](https://paper.dropbox.com/doc/Lang-Team-Agenda--Abi25xmcLMT81rd4DEerBHsfAg-bbhfd7hrR26fDoz8Hsb2v) 4 | 5 | Topics covered: 6 | 7 | - Issue #51497 -- shadowing method resolution 8 | - #47168 -- suggestions, integer conversion, and `as` 9 | - RFC #2582 -- `&raw` operations 10 | - unused drop arguments in async await 11 | - fcp proposal 12 | -------------------------------------------------------------------------------- /minutes/2019-06-06.md: -------------------------------------------------------------------------------- 1 | # 2019.06.06 2 | 3 | - [Video recording](https://youtu.be/yR7rTfgdX9A) 4 | - [Dropbox paper](https://paper.dropbox.com/doc/T-Lang-Meeting-2019.06.06--AeiJ7bDBLuZZhphj0jWRivxFAg-rozbbUauo8gNtf1CBl8cb) 5 | - Main topic: std-aware cargo 6 | -------------------------------------------------------------------------------- /minutes/2019.04.18.md: -------------------------------------------------------------------------------- 1 | Renamed to [2019-04-18.md](2019-04-18.md) 2 | -------------------------------------------------------------------------------- /minutes/2019.09.26.md: -------------------------------------------------------------------------------- 1 | Renamed to [2019-09-26.md](2019-09-26.md) 2 | -------------------------------------------------------------------------------- /minutes/2020-06-15.md: -------------------------------------------------------------------------------- 1 | # T-Lang Meeting: Current meeting 2 | 3 | [Recording available](https://youtu.be/WB1EywAs0I4) 4 | 5 | ## Action item 6 | - Niko to reach out to wg-grammar around writing up a “what is status” thing 7 | - Niko to prep a write-up for [auto-trait-lifetime interactions](https://github.com/rust-lang/rust/issues/64552) 8 | - scott to post comment on “elide array size” RFC 9 | - Josh to invite Ryan to present state of safe transmute 10 | - Felix to investigate https://github.com/rust-lang/rust/issues/66740 and https://github.com/rust-lang/rust/issues/66741 before next meeting 11 | - Niko to prepare a meeting proposal for WF checks on type parameters 12 | - https://github.com/rust-lang/rust/pull/69741 13 | - Josh to write a comment [+T-Lang Meeting: Current meeting: Discussion-about-https://githu](https://paper.dropbox.com/doc/T-Lang-Meeting-Current-meeting-Discussion-about-httpsgithu-nRfrSxCbfeo9q7fEYogZQ#:h2=Discussion-about-https://githu) 14 | - Felix to analyze https://github.com/rust-lang/rust/issues/66740 and form an opinion. 15 | - Niko to write a comment discussing the idea of adding raw pointer methods to `AtomicUse` to make it *possible* to correct https://github.com/rust-lang/rust/issues/55005. 16 | - Reminder: another “help wanted” lang-team proposal raw pointer methods? 17 | - Niko to comment on https://github.com/rust-lang/rfcs/pull/2545 to cancel FCP and encourage moving to MCP process to consider revitalizing. 18 | - Also close some older FCPs and consider re-opening them. 19 | ## Agenda 20 | - Add new MCPs and meeting proposals to the [Lang Team Project Board](https://github.com/rust-lang/lang-team/projects/2) 21 | - Review [Lang Team Project Board:](https://github.com/rust-lang/lang-team/projects/2) 22 | - Active items 23 | - Major Change Proposals 24 | - Meeting Proposals 25 | - Review [P-high issues](https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AP-high+label%3AT-lang) 26 | - Review [Nominated PRs](https://github.com/rust-lang/rust/pulls?q=is%3Aopen+is%3Apr+label%3AI-nominated+label%3AT-lang) 27 | - Review [Nominated issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AI-nominated+label%3AT-lang+) 28 | - Review [newly created RFCs](https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AT-lang) 29 | - Review [Nominated RFCs](https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AI-nominated+label%3AT-lang) 30 | - Review [rfcbot pending list](https://rfcbot.rs/) 31 | 32 | 33 | ## Notes from meeting: 34 | 35 | 36 | https://github.com/rust-dev-tools/fmt-rfcs/issues/152 37 | 38 | 39 | **Update to inline assembly** 40 | 41 | Read [comment here](https://github.com/rust-lang/lang-team/issues/20#issuecomment-644324937) 42 | 43 | **Update to FFI project group** 44 | 45 | Read [comment here](https://github.com/rust-lang/lang-team/issues/19#issuecomment-642951381) 46 | 47 | https://github.com/rust-lang/lang-team/issues/19 48 | 49 | 50 | Example: 51 | 52 | 53 | fn foo(x: &mut u32) { 54 | *x += 1; // under stacked borrow, this assigned can be moved below the call to bar 55 | bar(); 56 | } 57 | 58 | fn bar() { } 59 | 60 | **Update to const evaluation** 61 | 62 | [Read comment here](https://github.com/rust-lang/lang-team/issues/22#issuecomment-644326659) 63 | 64 | Josh points out that inline assembly has a “const operand”, is there an interaction here? 65 | 66 | **Discussion about https://github.com/rust-lang/rust/issues/73191** 67 | 68 | One challenge is that the name resolution code doesn’t (today) have to look at the RHS of a type alias, and it knows that `type Foo = …` only introduces a name in the type namespace (no doubt relevant to resolving some cycles). 69 | 70 | Common use case for `type` is to “pre-specify” generic types: 71 | 72 | 73 | struct Foo(T); 74 | 75 | type Bar = Foo; 76 | 77 | Bar(22) // doesn't work today 78 | 79 | Can you use them in patterns? [Not today](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6e15f976dc2491a5839813a9ee250e0e). 80 | 81 | 82 | struct Foo(u32); 83 | 84 | type Bar = Foo; 85 | 86 | fn gimme(x: Bar) { 87 | match x { 88 | Bar(22) => (), 89 | Bar(_) => (), 90 | } 91 | } 92 | 93 | fn main() { } 94 | 95 | Next steps: 96 | 97 | - Loop in petrochenkov to get their opinion. 98 | - Maybe move to a MCP to prototype the new process? 99 | 100 | **Discussion around RFC 2545** 101 | 102 | - https://github.com/rust-lang/rfcs/pull/2545 103 | - Can we unstick this? 104 | - Josh: I’d be ok with closing this and encouraging folks to open a change proposal with the underlying motivation 105 | - Niko to cancel FCP and encourage opening an MCP. 106 | 107 | **Topic: talk about moving away from Zoom** 108 | 109 | - https://www.npr.org/2020/06/12/876351501/zoom-acknowledges-it-suspended-activists-accounts-at-china-s-request 110 | - https://twitter.com/nicoagrant/status/1268020841054269440 111 | - Requirements and what features to do we make use of? 112 | - Screen sharing, especially sharing a specific window (and not the whole screen). 113 | - Cloud recording - upload to YouTube 114 | - Transcription? 115 | - “Working” with larger numbers of participants 116 | - Ideally, working web-only client (including in Firefox) 117 | - What are technical problems with Zoom 118 | - No web-only client 119 | - Paid account required for features we use 120 | - Hard if no Mozilla employee is around to do recording 121 | - Alternatives: 122 | - jitsi hosted instance? 123 | 124 | -------------------------------------------------------------------------------- /minutes/2020-06-22.md: -------------------------------------------------------------------------------- 1 | # T-Lang Meeting: Current meeting 2 | 3 | [Recording available](https://youtu.be/_ZSlR4X7IPY) 4 | 5 | ## Action item 6 | - Niko to reach out to wg-grammar around writing up a “what is status” thing 7 | - Niko to prep a write-up for [auto-trait-lifetime interactions](https://github.com/rust-lang/rust/issues/64552) 8 | - scott to post comment on “elide array size” RFC 9 | - Josh to invite Ryan to present state of safe transmute 10 | - Felix to investigate https://github.com/rust-lang/rust/issues/66740 and https://github.com/rust-lang/rust/issues/66741 before next meeting 11 | - ~~Niko to prepare a meeting proposal for WF checks on type parameters~~ 12 | - https://github.com/rust-lang/rust/pull/69741 13 | - Josh to write a comment [+T-Lang Meeting: Current meeting: Discussion-about-https://githu](https://paper.dropbox.com/doc/T-Lang-Meeting-Current-meeting-Discussion-about-httpsgithu-nRfrSxCbfeo9q7fEYogZQ#:h2=Discussion-about-https://githu) 14 | - Felix to analyze https://github.com/rust-lang/rust/issues/66740 and form an opinion. 15 | - ~~Niko to write a comment discussing the idea of adding raw pointer methods to~~ `~~AtomicUse~~` ~~to make it~~ ~~*possible*~~ ~~to correct https://github.com/rust-lang/rust/issues/55005.~~ 16 | - Reminder: another “help wanted” lang-team proposal raw pointer methods? 17 | - ~~Niko to comment on https://github.com/rust-lang/rfcs/pull/2545 to cancel FCP and encourage moving to MCP process to consider revitalizing.~~ 18 | - Also close some older FCPs and consider re-opening them. 19 | - Lower priority of https://github.com/rust-lang/rust/issues/68015 and add as a blocker to CoerceUnsized 20 | ## Agenda 21 | - Add new MCPs and meeting proposals to the [Lang Team Project Board](https://github.com/rust-lang/lang-team/projects/2) 22 | - Review [newly created RFCs](https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AT-lang) 23 | - Review [Lang Team Project Board:](https://github.com/rust-lang/lang-team/projects/2) 24 | - Active items 25 | - Major Change Proposals 26 | - Meeting Proposals 27 | - Review [P-high issues](https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AP-high+label%3AT-lang) 28 | - Review [Nominated PRs](https://github.com/rust-lang/rust/pulls?q=is%3Aopen+is%3Apr+label%3AI-nominated+label%3AT-lang) 29 | - Review [Nominated issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AI-nominated+label%3AT-lang+) 30 | - Review [Nominated RFCs](https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AI-nominated+label%3AT-lang) 31 | - Review [rfcbot pending list](https://rfcbot.rs/) 32 | 33 | 34 | ## Notes from meeting: 35 | 36 | **FFI-Unwind** 37 | 38 | 39 | - Not inclined to revisit questions like keyword notation (at least Niko is not) 40 | - Would rather not have `"system"` mean unwind if `"C"` excludes unwinding, would want to have a consistent opt-in 41 | - Could we have a lint for `#[unwind(allowed)]` that warns if the ABI does not permit unwinding? 42 | - We are going to remove this attribute but it’ll require some sort of transition period as people are using it today (on nightly). 43 | - Ideal: 44 | - Make this imply the newer ABI 45 | - Warn and encourage folks to migrate to the newer ABI 46 | 47 | **Issue 72012** 48 | 49 | 50 | - Soundness problem with target feature 51 | - Reviewed the various solutions proposed 52 | - Unsafe to reference without calling 53 | - this breaks existing code but is also a more complex fix to implement, somewhat “unnatural” to not be able to refactor `foo()` to `let x = foo; x()` 54 | - “Fast fix” 55 | - functions that declare “target feature” do not implement `Fn` and friends 56 | - Josh’s ideal alternative 57 | - it is “unsafe” for functions that declare “target feature” to implement `Fn` and friends 58 | - i.e., you can only use this implementation in an unsafe block 59 | - but this is not an option (today) because it is a concept that the language supports, it would be like an impl that is unsafe to use 60 | - or — it is only possible within a function that has the same target feature set 61 | - it’s ok that functions can escape in this case because you’ve already “demonstrated” that you are capable of supporting those target features 62 | - conceptually these are kind of “impls” with where clauses that test the environment (“am I 63 | - Observation: 64 | - you can kind of model the “preferred” solution using closures, but not quite, because closures aren’t allowed to use the target feature of their enclosing item ([example](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=eaf22b1eb397b52b5c312d1a9de347c7)) 65 | - answer is probably yes 66 | - Niko’s proposal: 67 | - Accept the PR that says fns with target-feature declared do not implement the Fn traits 68 | - Address the question of closures and what target features they have available, which also provides a workaround for the above case 69 | - If in the future we wish to do so, we can create some conditions under which fns with target-feature may implement the Fn traits (backwards compatibly), but it involves adding some new concepts to the trait system (e.g., impls usable only with a given target feature in scope, or unsafe impls). 70 | 71 | 72 | // Example of escaping: 73 | 74 | #[target_feature(enable="avx")] 75 | fn use_avx() -> Box { 76 | let x: Box = Box::new(also_use_avx); 77 | x 78 | } 79 | 80 | #[target_feature(enable="avx")] 81 | fn also_use_avx() { 82 | println!("Hello from AVX") 83 | } 84 | 85 | fn main() { 86 | let y = use_avx(); 87 | } 88 | 89 | 90 | // 91 | 92 | #[target_feature(enable="avx")] 93 | fn use_avx() -> Box { } 94 | 95 | 96 | impl … { // For the type of `use_avx` 97 | #[target_feature(enable="avx")] 98 | fn as_fn(&self) → impl Fn(…); 99 | } 100 | 101 | fn main() { 102 | let y = unsafe { use_avx.as_fn() }; 103 | } 104 | 105 | #[target_feature(enable="avx")] 106 | fn another_avx() -> Box { 107 | use_avx.as_fn() // no unsafe needed 108 | } 109 | 110 | -------------------------------------------------------------------------------- /minutes/2020-06-29.md: -------------------------------------------------------------------------------- 1 | # T-Lang Meeting: Current meeting 2 | 3 | [Recording available](https://youtu.be/QE4MbWkJxYQ) 4 | 5 | ## Action item 6 | - Niko to reach out to wg-grammar around writing up a “what is status” thing 7 | - Niko to prep a write-up for [auto-trait-lifetime interactions](https://github.com/rust-lang/rust/issues/64552) 8 | - scott to post comment on “elide array size” RFC 9 | - Josh to invite Ryan to present state of safe transmute 10 | - Felix to investigate https://github.com/rust-lang/rust/issues/66740 and https://github.com/rust-lang/rust/issues/66741 before next meeting 11 | - ~~Niko to prepare a meeting proposal for WF checks on type parameters~~ 12 | - https://github.com/rust-lang/rust/pull/69741 13 | - Josh to write a comment [+T-Lang Meeting: Current meeting: Discussion-about-https://githu](https://paper.dropbox.com/doc/T-Lang-Meeting-Current-meeting-Discussion-about-httpsgithu-nRfrSxCbfeo9q7fEYogZQ#:h2=Discussion-about-https://githu) 14 | - Felix to analyze https://github.com/rust-lang/rust/issues/66740 and form an opinion. 15 | - ~~Niko to write a comment discussing the idea of adding raw pointer methods to~~ `~~AtomicUse~~` ~~to make it~~ ~~*possible*~~ ~~to correct https://github.com/rust-lang/rust/issues/55005.~~ 16 | - Reminder: another “help wanted” lang-team proposal raw pointer methods? 17 | - ~~Niko to comment on https://github.com/rust-lang/rfcs/pull/2545 to cancel FCP and encourage moving to MCP process to consider revitalizing.~~ 18 | - Also close some older FCPs and consider re-opening them. 19 | - Lower priority of https://github.com/rust-lang/rust/issues/68015 and add as a blocker to CoerceUnsized 20 | ## Agenda 21 | - Add new MCPs and meeting proposals to the [Lang Team Project Board](https://github.com/rust-lang/lang-team/projects/2) 22 | - Review [newly created RFCs](https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AT-lang) 23 | - Review [Lang Team Project Board:](https://github.com/rust-lang/lang-team/projects/2) 24 | - Active items 25 | - Major Change Proposals 26 | - Meeting Proposals 27 | - Review [P-high issues](https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AP-high+label%3AT-lang) 28 | - Review [Nominated PRs](https://github.com/rust-lang/rust/pulls?q=is%3Aopen+is%3Apr+label%3AI-nominated+label%3AT-lang) 29 | - Review [Nominated issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AI-nominated+label%3AT-lang+) 30 | - Review [Nominated RFCs](https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AI-nominated+label%3AT-lang) 31 | - Review [rfcbot pending list](https://rfcbot.rs/) 32 | 33 | 34 | ## Notes from meeting: 35 | 36 | None 37 | -------------------------------------------------------------------------------- /minutes/2020-07-06.md: -------------------------------------------------------------------------------- 1 | # T-Lang Meeting: Current meeting 2 | 3 | * [Watch the recording](https://youtu.be/Cajj5L7fHzw) 4 | 5 | ## Action item 6 | - Niko to reach out to wg-grammar around writing up a “what is status” thing 7 | - Niko to prep a write-up for [auto-trait-lifetime interactions](https://github.com/rust-lang/rust/issues/64552) 8 | - scott to post comment on “elide array size” RFC 9 | - Lower priority of https://github.com/rust-lang/rust/issues/68015 and add as a blocker to CoerceUnsized 10 | - Niko to postpone cancel FCP on [RFC 2522](https://github.com/rust-lang/rfcs/pull/2522#issuecomment-415551732) and close as postponed, encouraging folks to consider opening an MCP for parts of the proposal and move it forward that way. 11 | ## Agenda 12 | - Add new MCPs and meeting proposals to the [Lang Team Project Board](https://github.com/rust-lang/lang-team/projects/2) 13 | - Review [newly created RFCs](https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AT-lang) 14 | - Review [Lang Team Project Board:](https://github.com/rust-lang/lang-team/projects/2) 15 | - Active items 16 | - Major Change Proposals 17 | - Meeting Proposals 18 | - Review [P-high issues](https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AP-high+label%3AT-lang) 19 | - Review [Nominated PRs](https://github.com/rust-lang/rust/pulls?q=is%3Aopen+is%3Apr+label%3AI-nominated+label%3AT-lang) 20 | - Review [Nominated issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AI-nominated+label%3AT-lang+) 21 | - Review [Nominated RFCs](https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AI-nominated+label%3AT-lang) 22 | - Review [rfcbot pending list](https://rfcbot.rs/) 23 | 24 | 25 | ## Notes from meeting: 26 | 27 | **Issue** https://github.com/rust-lang/rust/issues/68354: mixing by-move and by-ref 28 | 29 | Summary of what the issue is talking about: 30 | 31 | 32 | let foo = (String:new(), String:new()); 33 | match foo { 34 | (ref x, y) => { // feature-gated today, but now works 35 | } 36 | } 37 | 38 | 39 | let foo = (&Some(String::new()), String::new()); 40 | match foo { 41 | (Some(x), y) => { /* mixes with default binding modes */ } 42 | } 43 | 44 | [Left this comment.](https://github.com/rust-lang/rust/issues/68354#issuecomment-654425636) 45 | 46 | **FCP on PR:** https://github.com/rust-lang/rust/pull/74060 47 | 48 | 49 | - Took an intentionally conservative approach around const generics in the beginning. 50 | - This PR now implements various traits for *arbitrary* lengths, rather than only “up to the length N”. 51 | - This commits us to the notion of having at least a private notion of const generics for usage by std. 52 | - [Related Zulip conversation](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/stable.20subset.20of.20const.20generics/near/202925130). 53 | 54 | **FCP on https://github.com/rust-lang/rust/issues/73631** 55 | 56 | 57 | - Assumption that this makes is that once you run code with a given target feature, you will always have that target feature available. 58 | - In theory you could have some complex architecture where you have asymmetric multiprocessing that has distinct capabilities: 59 | - But this would break a huge amount of code in the wild that assumes you can check the CPUID once and then cache that result. 60 | - There has been discussion in the linux community that in such a scenario, you would get back the universal subset available, and would have to “opt in” to observing features that are specific to your sort of core. 61 | - New type of UB: “taking a target feature away from your process after having run code that uses that target feature is UB”. 62 | - We could change this in the future if we need to deal with complex asymmetric multiprocessing scenarios as described above. 63 | - Definition of the unsafe proof obligation to call a target-feature: 64 | - You must show that the target-feature is available while the function executes *and whatever may escape from that function*. 65 | - This emphasized condition is trivial in the case where cpu features never change. 66 | - In a hybrid architecture where cpu features can change, you would have to know whether fn and closure pointers escape and for how long. This may imply new annotations that assure you that they do not escape or perhaps adding a lifetime annotation. 67 | - Lifetime annotations could also be useful for dynamic loading/unloading scenarios where functions get unloaded. 68 | 69 | 70 | **FCP on** [rust-lang/rfcs#2522](https://github.com/rust-lang/rfcs/pull/2522) 71 | 72 | 73 | - Niko plans to cancel and close as postponed, encouraging folks to consider opening an MCP for parts of the proposal and move it forward that way. 74 | 75 | 76 | https://github.com/rust-lang/rfcs/pull/2522 77 | 78 | 79 | **FCP on** https://github.com/rust-lang/rfcs/pull/2632 80 | 81 | 82 | - Would be nice to resolve this, we don’t normally keep RFCs open while we experiment, but we have to review the details, and would be nice to have ecstatic-morse around for this. 83 | 84 | -------------------------------------------------------------------------------- /minutes/2020-07-20.md: -------------------------------------------------------------------------------- 1 | # T-Lang Meeting: Current meeting 2 | 3 | [Recording available](https://youtu.be/9RC8su7AxhY) 4 | 5 | ## Action item 6 | - Niko to reach out to wg-grammar around writing up a “what is status” thing 7 | - scott to post comment on “elide array size” RFC (done) 8 | - 9 | ## Agenda 10 | - Add new MCPs and meeting proposals to the [Lang Team Project Board](https://github.com/rust-lang/lang-team/projects/2) 11 | - Review [newly created RFCs](https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AT-lang) 12 | - Review [Lang Team Project Board:](https://github.com/rust-lang/lang-team/projects/2) 13 | - Active items 14 | - Major Change Proposals 15 | - Meeting Proposals 16 | - Review [P-high issues](https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AP-high+label%3AT-lang) 17 | - Review [Nominated PRs](https://github.com/rust-lang/rust/pulls?q=is%3Aopen+is%3Apr+label%3AI-nominated+label%3AT-lang) 18 | - Review [Nominated issues](https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3AI-nominated+label%3AT-lang+) 19 | - Review [Nominated RFCs](https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AI-nominated+label%3AT-lang) 20 | - Review [rfcbot pending list](https://rfcbot.rs/) 21 | 22 | 23 | ## Notes from meeting: 24 | 25 | **async foundations update: On streams and lending streams** 26 | 27 | 28 | - there are some problems that arise here that are general problems for Rust 29 | - adding helper methods to `Stream` 30 | - there are coherence issues that arise if you have 31 | - `impl LendingStream for impl Stream` 32 | - and `impl LendingStream for Box` 33 | - and `impl Stream for Box` 34 | - `impl Stream for L where L: LendingStream = I>` (“the lifetime of the item (`'``a`) doesn’t depend on the lifetime of the LendingStream”) 35 | - This could avoid someof the coherence issues 36 | 37 | **MCPs** 38 | 39 | 40 | - Going to look for liaisons not in lang team 41 | - Going to post warnings on older MCPs that we will close if we *can’t* find a liaison 42 | - Leave a comment if you are interested 43 | 44 | **stabilize ptr_offset_from #74238** 45 | 46 | 47 | - Undefined behavior to request an offset from two unrelated pointers 48 | 49 | **Tracking issue for "implicit named arguments for formatting macros"** #67984 50 | 51 | Some relevant issues: 52 | 53 | - You should be able to panic with arbitrary values 54 | - You should be able to panic with literal strings, at least some of the time 55 | - i.e., what if it contains `{foo}` 56 | - Should be able to avoid losing functionality compared to the current system 57 | - so people can always use the new system 58 | - `fmt::Arguments::as_str()`: https://github.com/rust-lang/rust/issues/74442 59 | - Niko’s proposal for “sense of this meeting” 60 | - We are in favor of making this transition as part of an Edition change 61 | - We would like to see a proposal that 62 | - enables the new-style references 63 | - preserves existing capabilities, possibly with a more explicit syntax 64 | - can be automatically transitioned across edition boundary 65 | 66 | **2021 Edition draft RFC** 67 | 68 | 69 | - Wanted to highlight the [draft RFC proposal](https://hackmd.io/jJflujmLS_-sFPUkYo417g) that nikomatsakis created with Steve, definitely impacts the lang team’s work. 70 | - Related to idiom lints: 71 | - Do we need a transition period? 72 | - Not really, because you have to opt-in to the new edition 73 | 74 | **Tracking issue for RFC 2582, `&raw [mut | const] $place` (raw_ref_op) #64490** 75 | 76 | 77 | - Niko would like to stabilize `raw_ref!` macro 78 | - Ralf had [examples of people using it](https://github.com/rust-lang/rust/issues/64490#issuecomment-657089537) and said they would be willing to prepare a stabilization PR 79 | 80 | 81 | -------------------------------------------------------------------------------- /minutes/2020-09-14.md: -------------------------------------------------------------------------------- 1 | # T-lang meeting agenda 2 | 3 | * Meeting date: 2020-09-14 4 | * [Watch the recording](https://youtu.be/0tl30zIVJoU) 5 | 6 | ## Pending proposals 7 | - "MCP: per-edition preludes" [lang-team#44](https://github.com/rust-lang/lang-team/issues/44) 8 | 9 | ## Project board review 10 | 11 | Review the [Lang team project board](https://github.com/rust-lang/lang-team/projects/2) and get updates 12 | 13 | 14 | ## Nominated RFCs 15 | - "Safer Transmute" [rfcs#2981](https://github.com/rust-lang/rfcs/pull/2981) 16 | 17 | ## P-high issues 18 | - "Coherence can be bypassed by an indirect impl for a trait object" [rust#57893](https://github.com/rust-lang/rust/issues/57893) 19 | 20 | ## Nominated issues and PRs 21 | - "Use implicit (not explicit) rules for promotability by default in `const fn`" [rust#75502](https://github.com/rust-lang/rust/pull/75502) 22 | - "Permit uninhabited enums to cast into ints" [rust#76199](https://github.com/rust-lang/rust/pull/76199) 23 | - "Lint on implicit ABI in extern fn and extern 'mod'" [rust#76219](https://github.com/rust-lang/rust/pull/76219) 24 | - Impact is non-trivial, we likely want to land this as an edition lint targeting 2024 (warn in 2021) 25 | - Niko and Josh: would not want to warn without a machine fix 26 | - Consensus from meeting: 27 | - Land PR with allow-by-default 28 | - FCP a PR that makes it warn-by-default and has a machine-applicable rustfix, also tie it to 2021 Edition 29 | - Mark to post comment on the PR 30 | 31 | ## Ad-hoc topics 32 | 33 | * boats: https://github.com/rust-lang/rfcs/pull/2984 34 | * Niko had proposed a design meeting on [RFC 2580](https://github.com/rust-lang/lang-team/issues/55) 35 | * [RFC 2984](https://github.com/rust-lang/rfcs/pull/2984) ties this to extern types 36 | * Consensus from before was that we did not want to add a (static) notion of "truly unsized" as opposed to "dynamically sized" (`?Sized` today). 37 | * If we wanted to settle the behavior towards this interpretation, we would stabilize some aspect of extern types and modify the functions to panic (probably). 38 | * Consider a project group around custom DST? 39 | * How much is this a priority *now*? 40 | * Also, this may overlap with the interests of folks from safe transmute group. 41 | * Parsing and protocol applications often require both safe transmute and consist of interesting data structures where you have variable length with a fixed header and that sort of thing. 42 | * Same approach of trying to find a "minimal kernel" so that we can push more and more into the crate ecosystem. 43 | * Good to connect to priorities 44 | * e.g., "safer unsafe" code 45 | * C++ interop, perhaps? 46 | * Point being that you can do a lot of this stuff with grody unsafe code but to do with safe code you need extensions to the language 47 | * Consensus from this meeting 48 | * We are interested in seeing this space move forward 49 | * But still skeptical of introducing new `?DynSized` trait for the extern use case 50 | -------------------------------------------------------------------------------- /minutes/2020-09-21.md: -------------------------------------------------------------------------------- 1 | # t-lang 2020 09 21 2 | 3 | # T-lang meeting agenda 4 | - Meeting date: 2020-09-21 5 | ## Attending 6 | - Team members: scott, niko, josh, boats 7 | - Others: simulacrum, areredify, Lokathor, lcnr 8 | ## Before meeting checklist 9 | [x] Update the project board with new proposals 10 | [ ] Update the project board with new RFCs 11 | ## Action items 12 | - Mark to write comment on #73394 13 | - Lang team to review safer transmute RFC 14 | - Lang team to review rfcs#2909 15 | - Niko to schedule meetings for upcoming weeks: 16 | - Next: https://github.com/rust-lang/lang-team/issues/55 17 | - Contact authors of paper from https://github.com/rust-lang/lang-team/issues/53 and see if they’re interested in talking to us and on what schedule 18 | ## Pending proposals 19 | - "MCP: per-edition preludes" [lang-team#44](https://github.com/rust-lang/lang-team/issues/44) 20 | - "MCP: Rust-style `#[inline]` attribute." [lang-team#56](https://github.com/rust-lang/lang-team/issues/56) 21 | ## Project board review 22 | 23 | Review the [Lang team project board](https://github.com/rust-lang/lang-team/projects/2) and get updates 24 | 25 | ## raw_ref_macros 26 | 27 | There was a proposal to stop using `GetElementPointerInBounds` for references that go through raw references (e.g., `&(*x).y` where `x: *mut T`). May remove some optimization potential, but makes code work more easily. There might even be an option for LLVM to add `GetElementPointerNoWrap` or some intermediate variant. 28 | 29 | Simon’s blocking concern seems to be an orthogonal concern for a feature that can be added in the future: 30 | 31 | - `&x.f` is UB if `f` is a packed field with an unaligned offset today, regardless of whether `x` is a valid reference 32 | - supporting “offset of” is indeed a plausible extension and we should talk about it, but it’s a backwards compatible change, and need not block progress here 33 | - some of lang team is in favor of making `raw_ref!((*n).f)` work where `n` is null but we should consider it separately 34 | 35 | Mark to write comment on https://github.com/rust-lang/rust/issues/73394 36 | 37 | ## Nominated RFCs 38 | - "Destructuring assignment" [rfcs#2909](https://github.com/rust-lang/rfcs/pull/2909) 39 | 40 | Last time we talked about this, there was controversy about ref and binding modes. The RFC now skips that and is narrowed to a subset of pattern matching. Ready for lang team sign-off. 41 | 42 | ## P-high issues on rust-lang/rust 43 | - "Coherence can be bypassed by an indirect impl for a trait object" [rust#57893](https://github.com/rust-lang/rust/issues/57893) 44 | ## Nominated PRs and issues on rust-lang/rust 45 | - "Permit uninhabited enums to cast into ints" [rust#76199](https://github.com/rust-lang/rust/pull/76199) 46 | 47 | 48 | ## Meetings: 49 | - This Wed → backlog bonanza 50 | - Next: https://github.com/rust-lang/lang-team/issues/55 51 | - Contact authors of paper from https://github.com/rust-lang/lang-team/issues/53 and see if they’re interested in talking to us and on what schedule 52 | 53 | -------------------------------------------------------------------------------- /minutes/2020-09-28.md: -------------------------------------------------------------------------------- 1 | # T-lang meeting agenda 2 | 3 | * Meeting date 2020-09-28 4 | 5 | ## Attendance 6 | 7 | * Team members: Josh, boats, scott 8 | * Others: simulacrum, areredify, connor horman, Lokathor 9 | 10 | ## Before meeting checklist 11 | 12 | * [ ] Update the project board with new proposals 13 | * [ ] Update the project board with new RFCs 14 | 15 | ## Pending proposals 16 | - "MCP: Rust-style `#[inline]` attribute." [lang-team#56](https://github.com/rust-lang/lang-team/issues/56) 17 | - Closed 18 | 19 | ## Project board review 20 | 21 | Review the [Lang team project board](https://github.com/rust-lang/lang-team/projects/2) and get updates 22 | - Re-review ! and fallback, and RFC 2229, with Niko present 23 | 24 | ## Nominated RFCs 25 | - No nominated RFCs this time. 26 | 27 | ## P-high issues on rust-lang/rust 28 | - "Coherence can be bypassed by an indirect impl for a trait object" [rust#57893](https://github.com/rust-lang/rust/issues/57893) 29 | 30 | ## Nominated PRs and issues on rust-lang/rust 31 | - "Lint for unused borrows as part of `UNUSED_MUST_USE`" [rust#76894](https://github.com/rust-lang/rust/pull/76894) 32 | - "passes: `check_attr` on more targets" [rust#77015](https://github.com/rust-lang/rust/pull/77015) 33 | 34 | ## New meeting proposal 35 | 36 | Unsafe Code Guidelines (UCG) group needs a design meeting slot in the future, to discuss a collection of small proposals. 37 | - Lokathor to file issue and get it on the lang team board 38 | -------------------------------------------------------------------------------- /minutes/2020-10-12.md: -------------------------------------------------------------------------------- 1 | # T-lang meeting agenda 2 | 3 | * Meeting date 2020-10-12 4 | 5 | ## Attendance 6 | 7 | * Team members: Niko, Scott, boats 8 | * Others: simulacrum, Lokathor, areredify 9 | 10 | ## Before meeting checklist 11 | 12 | * [x] Update the project board with new proposals 13 | * [ ] Update the project board with new RFCs 14 | 15 | ## Pending proposals 16 | 17 | * "MCP: pub(macro)" [lang-team#59](https://github.com/rust-lang/lang-team/issues/59) 18 | * inclined to place in FCP for close because: 19 | * macros are imperfect, we know, but 20 | * this problem was meant to be solved by hygiene 21 | * adding syntax doesn't make solving it easier 22 | * we'd rather wait and address macros 2.0 / hygiene more holistically 23 | * "Restrict promotion to infallible operations" [lang-team#58](https://github.com/rust-lang/lang-team/issues/58) 24 | * we would like an RFC that pulls together the overall plan 25 | * supercedes old promotion RFC, builds on explicit syntax recently introduced 26 | * role of this RFC is to surface this change to the community and document/justify it 27 | * doesn't block implementation PRs from landing 28 | * like https://github.com/rust-lang/rust/pull/77526 29 | 30 | ## Project board review 31 | 32 | Review the [Lang team project board](https://github.com/rust-lang/lang-team/projects/2) and get updates 33 | 34 | ## Nominated RFCs 35 | - "Safer Transmute" [rfcs#2981](https://github.com/rust-lang/rfcs/pull/2981) 36 | 37 | ## P-high issues on rust-lang/rust 38 | - No P-high issues this time. 39 | 40 | ## Nominated PRs and issues on rust-lang/rust 41 | - "Tracking issue for experiments around coercions, generics, and Copy type ergonomics" [rust#44619](https://github.com/rust-lang/rust/issues/44619) 42 | - Mark to move this content to a design note in the lang-team repo 43 | - We are still open to project proposals in this area but the issue isn't serving much function 44 | - probably what's required is implementation experimentation 45 | - "resolve: Do not put nonexistent crate `meta` into prelude" [rust#75802](https://github.com/rust-lang/rust/pull/75802) 46 | - un-nominated, no update 47 | - "Switch `mutable_borrow_reservation_conflict` lint to deny by default" [rust#76104](https://github.com/rust-lang/rust/pull/76104) 48 | - Niko to leave a comment and we can circle back next week, would be good to have Josh around 49 | - "passes: `check_attr` on more targets" [rust#77015](https://github.com/rust-lang/rust/pull/77015) 50 | - Discussed the question of whether we should revisit our backwards compatibility policies 51 | - in particular, this is clearly a bug fix but we could choose to make it a deny-by-default lint nonetheless and phase in (e.g.) over an edition boundary if we really wanted a hard error 52 | - For now decided to land this change but to revisit this topic in future 53 | - If there is more breakage than anticipated we are happy to back out 54 | - "`use dep1::foo as dep1` is considered ambiguous on nightly but not beta" [rust#77586](https://github.com/rust-lang/rust/issues/77586) 55 | - Seems like a bug, we are content to let it ride the trains as it was recently introduced 56 | - No crater data, but the person who made the report is ok with the breakage 57 | - The ambiguity error makes sense to us 58 | - Again highlights the need for a more explicit policy around these sorts of decisions 59 | - "New "warning incompatible with previous forbid in same scope" error" [rust#77713](https://github.com/rust-lang/rust/issues/77713) 60 | * https://github.com/rust-lang/rust/issues/70819 was the original issue being fixed, was fixed by https://github.com/rust-lang/rust/pull/77534 61 | * In Rust 1.42, if you put `-Funused` and `-Aunused` on the command line, it was interpreted as a forbid and resulted 62 | * But in code, putting two attributes at the crate level was ignored (https://github.com/rust-lang/rust/issues/70819) 63 | * This code is in nightly but not in beta yet 64 | * Consensus points 65 | * definitely we should forbid in the crate if there is a forbid at the top level 66 | * because: if someone writes `forbid(unsafe_code)` and then someone PRs in some small line with `warn(unsafe_code)` on a module and then allow(unsafe_code) on an unsafe usage, that's really not what the person who wrote forbid wanted 67 | * note though that cap-lints does mean that you can't rely on forbid as a had guarantee (but also means that dependencies don't break) 68 | * top level should not be special, all levels should behave the same 69 | * we should at least warn, and maybe error, for `forbid` followed by `allow` 70 | * we can either accept, warn, or hard error for `allow` followed by `forbid` 71 | * On order dependence 72 | * There was some surprise at the idea of order dependence for top-level items 73 | * However other forms of attributes are order dependent (e.g., procedural macros) 74 | -------------------------------------------------------------------------------- /minutes/2020-10-19.md: -------------------------------------------------------------------------------- 1 | # T-lang meeting agenda 2 | 3 | * Meeting date 2020-10-19 4 | * [Watch the recording](https://youtu.be/VeTkLgD179Q) 5 | 6 | ## Attendance 7 | 8 | * Team members: Niko, Josh, scottmcm, pnkfelix 9 | * Others: simulacrum, connor horman 10 | 11 | ## Before meeting checklist 12 | 13 | * [x] Update the project board with new proposals 14 | * [x] Update the project board with new RFCs 15 | 16 | ## Pending proposals 17 | - "Restrict promotion to infallible operations" [lang-team#58](https://github.com/rust-lang/lang-team/issues/58) 18 | - can possibly move to a design note until we get an RFC 19 | - niko to reach out to ralf and check in on how to handle 20 | - "MCP: pub(macro)" [lang-team#59](https://github.com/rust-lang/lang-team/issues/59) 21 | - agree that this problem needs solving 22 | - might be a good use for wishlist to try and find people 23 | - (done) 24 | - "Types as const Parameters" [lang-team#61](https://github.com/rust-lang/lang-team/issues/61) 25 | - potentially nice simplification in the future; the idea of reifying more of type system into values is interesting 26 | - but builds on const generics, which are still in progress 27 | - lots of unknowns (e.g., how to get access to the "values", convert them back into types, etc) 28 | - scott to write a move to close and tag as FCP 29 | 30 | ## Design meeting planning 31 | 32 | - Getting consensus on lang team membership expectations (could do async) 33 | - [draft document](https://hackmd.io/qyfBQdcASom9Ab8TNmbdKg?view) 34 | - Lang team process tweaks (seconding/objections) 35 | - libs team has proposed [this charter](https://github.com/rust-lang/rfcs/pull/2979), has a lot of overlap compiler/lang 36 | - using seconding for approving MCP / proposal 37 | - using seconding to close/postpone RFCs 38 | - scheduling of design meetings, how to do it better 39 | - Discuss RFC 2580 (Pointer metadata and vtable) 55 40 | - 41 | - Schedule invited discussion with authors of Rust paper 42 | - https://github.com/rust-lang/lang-team/issues/53 43 | - following up on [this PLDI paper](https://cseweb.ucsd.edu/~yiying/RustStudy-PLDI20.pdf), to discuss sources of bugs and possible solutions 44 | - Backlog Bonanza 45 | - This week 46 | 47 | * Niko to follow up with a proposed schedule 48 | 49 | ## Project board review 50 | 51 | Review the [Lang team project board](https://github.com/rust-lang/lang-team/projects/2) and get updates 52 | 53 | ## Nominated RFCs 54 | - "RFC: -C export-executable-symbols" [rfcs#2841](https://github.com/rust-lang/rfcs/pull/2841) 55 | - "RFC: Supertrait item shadowing" [rfcs#2845](https://github.com/rust-lang/rfcs/pull/2845) 56 | - scottmcm read it and found it basically does all the things it should, discusses the key problems 57 | - most interesting thing: if you bound your generic to `T: Super`, `T: Sub`, `T: Super + Sub`, each has distinct meanings 58 | - `foo.bar()` would pick the method from super in the 1st case, from sub in the 2nd case, and be ambiguous in the 3rd case 59 | - also what happens from `T: Foo + Bar` where they share a method 60 | - presumably also applies to `T::Item` expansion 61 | - wait for boats to make a call whether to fcp merge 62 | 63 | ## P-high issues on rust-lang/rust 64 | - "New "warning incompatible with previous forbid in same scope" error" [rust#77713](https://github.com/rust-lang/rust/issues/77713) 65 | 66 | ## Nominated PRs and issues on rust-lang/rust 67 | - "Switch `mutable_borrow_reservation_conflict` lint to deny by default" [rust#76104](https://github.com/rust-lang/rust/pull/76104) 68 | - "`use dep1::foo as dep1` is considered ambiguous on nightly but not beta" [rust#77586](https://github.com/rust-lang/rust/issues/77586) 69 | - "New "warning incompatible with previous forbid in same scope" error" [rust#77713](https://github.com/rust-lang/rust/issues/77713) 70 | - "repr(transparent) on generic type skips "exactly one non-zero-sized field" check" [rust#77841](https://github.com/rust-lang/rust/issues/77841) 71 | - "Tracking issue for `X..`, `..X`, and `..=X` (`#![feature(half_open_range_patterns)]`)" [rust#67264](https://github.com/rust-lang/rust/issues/67264#) 72 | -------------------------------------------------------------------------------- /minutes/2020-10-26.md: -------------------------------------------------------------------------------- 1 | # T-lang meeting agenda 2 | 3 | * Meeting date 2020-10-26 4 | * [Watch the recording](https://youtu.be/FLPNAI8XRnw) 5 | 6 | ## Attendance 7 | 8 | * Team members: Niko, boats, Josh, scott, pnkfelix 9 | * Others: simulacrum, Mara, connor horman, Diggory Blake 10 | 11 | ## Before meeting checklist 12 | 13 | * [ ] Update the project board with new proposals 14 | * [ ] Update the project board with new RFCs 15 | 16 | ## Pending proposals 17 | - "Restrict promotion to infallible operations" (in FCP) [lang-team#58](https://github.com/rust-lang/lang-team/issues/58) 18 | - ready to merge, will merge after meeting 19 | - "Types as const Parameters" (in FCP) [lang-team#61](https://github.com/rust-lang/lang-team/issues/61) 20 | 21 | ## Project board review 22 | 23 | Review the [Lang team project board](https://github.com/rust-lang/lang-team/projects/2) and get updates 24 | 25 | ## Nominated RFCs 26 | - "RFC: -C export-executable-symbols" [rfcs#2841](https://github.com/rust-lang/rfcs/pull/2841) 27 | - "RFC: Supertrait item shadowing" [rfcs#2845](https://github.com/rust-lang/rfcs/pull/2845) 28 | - scott prepared an update that said "this is what I expected" 29 | - scott was ready to move to FCP but wanted to wait for boats 30 | - boats is in favor =) 31 | - **scott to fcp merge** 32 | 33 | ## P-high issues on rust-lang/rust 34 | - "New "warning incompatible with previous forbid in same scope" error" [rust#77713](https://github.com/rust-lang/rust/issues/77713) 35 | - Mark has produced [a summary comment with a proposal](https://github.com/rust-lang/rust/issues/77713#issuecomment-716649814) 36 | - One concern: we should not weaken behavior of forbid in nested scopes, that should remain a hard error 37 | - Scott: to me, if you say allow/forbid/warn/deny, it's fine to get warnings, the important thing is that the "forbid" is the one that wins 38 | - What about forbid with "warn" in a nested scope? Would leave those alone. 39 | - Key constraint: saying forbid at some level means forbid applies within, no matter what else you say at that level 40 | - **Mark to implement and see how it turns out** 41 | 42 | ## Nominated PRs and issues on rust-lang/rust 43 | - "Tracking issue for #[cfg(target_has_atomic = ...)]" [rust#32976](https://github.com/rust-lang/rust/issues/32976) 44 | - request for prioritization 45 | - what people probably want here is `cfg(accessible(...))`, really 46 | - **Mark to leave comment** 47 | - "Tracking issue for `X..`, `..X`, and `..=X` (`#![feature(half_open_range_patterns)]`)" [rust#67264](https://github.com/rust-lang/rust/issues/67264) 48 | - continued discussion 49 | - potential confusion about what `..X` means but that meaning is stable 50 | - `(..5).contains(&y)` should be same as `match y { ..5 => ... }` 51 | - patterns though are more common 52 | - and people are often trying to avoid caring if it is signed or unsigned 53 | - but it's not just `contains`, also look-ups in btrees etc 54 | - integer overlap checking is relevant too -- if you have an arm for negative cases, you'll get a lint 55 | - but maybe you are just not handling negatives by accident, and you don't realize the oversight 56 | - could use a clippy lint (or other lint) for signed cases using `..X` patterns 57 | - stabilization for `X..` case is not controversial, let's start with that 58 | - `..X` is comparatively rare 59 | - if you wanted to write type-agnostic code, and we supported associated constants fully, you could do something like `Bounded::MIN .. X` where `Bounded` is a trait implemented for `i32`, `u32`, etc 60 | - **scott to summarize this comment and make a call to action** 61 | - "`use dep1::foo as dep1` is considered ambiguous" [rust#77586](https://github.com/rust-lang/rust/issues/77586) 62 | - [revisted crater impact](https://github.com/rust-lang/rust/issues/77586#issuecomment-712888954) prompted Mark to suggest that we should keep this at least for Rust 2018 edition 63 | - [petrochenkov indicates it is not too hard to maintain](https://github.com/rust-lang/rust/issues/77586#issuecomment-714758171) 64 | - another possibility is to add a lint at some point to suggest folks add `::`, this would be required if we wanted to do an edition 65 | - another example below, presumably this errors? 66 | - **niko to leave comment recommending we revert the change for now** 67 | 68 | 69 | ``` 70 | pub mod foo { 71 | pub use dep1::foo as dep1; 72 | use xyz as dep1; 73 | } 74 | ``` 75 | 76 | - "repr(transparent) on generic type skips "exactly one non-zero-sized field" check" [rust#77841](https://github.com/rust-lang/rust/issues/77841) 77 | - niko floated a [specific proposal](https://github.com/rust-lang/rust/issues/77841#issuecomment-716575763) to treat structs as equivalent to `()` if they contain only 1-ZSTs 78 | - check your boxes or raise objections 79 | - "regression: target_feature no longer permitted in some places" [rust#78143](https://github.com/rust-lang/rust/issues/78143) 80 | - **decided to accept this as a bug fix** 81 | 82 | ## Nominated PRs and issues on rust-lang/rust that we didn't get to 83 | 84 | - "Add checking for no_mangle to unsafe_code lint" [rust#72209](https://github.com/rust-lang/rust/pull/72209) 85 | - [scott proposed merging](https://github.com/rust-lang/rust/pull/72209#issuecomment-692859048) some time back 86 | - "Switch `mutable_borrow_reservation_conflict` lint to deny by default" [rust#76104](https://github.com/rust-lang/rust/pull/76104) 87 | - [update from Ralf](https://github.com/rust-lang/rust/pull/76104#issuecomment-713151373): 88 | - in short, forbidding pre-existing borrows may be helpful but it may also not be sufficient, too early to tell 89 | - "Add built-in implementations of `Default` for function definition and…" [rust#77688](https://github.com/rust-lang/rust/pull/77688) 90 | - make zero-sized closures, function types implement Default 91 | - convenient but makes Default "well known" to the compiler 92 | - "consider assignments of union field of ManuallyDrop type safe" [rust#78068](https://github.com/rust-lang/rust/pull/78068) 93 | - "Assigning to Copy union fields is safe because that assignment will never drop anything. However, with #77547, unions may also have ManuallyDrop fields, and their assignments are currently still unsafe. That seems unnecessary though, as assigning ManuallyDrop does not drop anything either, and is thus safe even for union fields." 94 | - "Rename `overlapping_patterns` lint" [rust#78242](https://github.com/rust-lang/rust/pull/78242) 95 | -------------------------------------------------------------------------------- /minutes/2020-11-17.md: -------------------------------------------------------------------------------- 1 | # T-lang meeting agenda 2 | 3 | * Meeting date: 2020-11-17 4 | * [Watch the recording](https://youtu.be/t3-tF6cRZWw) 5 | 6 | ## Attendance 7 | 8 | * Team members: Niko, boats, Taylor, Josh, scott 9 | * Others: simulacrum, mara, lcnr, oliver 10 | 11 | ## Before meeting checklist 12 | 13 | * [ ] Update the project board with new proposals 14 | * [ ] Update the project board with new RFCs 15 | 16 | ## Pending proposals 17 | - "Add a `NOOP_METHOD_CALL` lint for methods which should never be directly called" [lang-team#67](https://github.com/rust-lang/lang-team/issues/67) 18 | - encourage Aaron to create the PR 19 | - "Disallow keywords as macro arguments names" [lang-team#68](https://github.com/rust-lang/lang-team/issues/68) 20 | - Last time we talked, it seemed like exploration was needed 21 | - Range of options: 22 | - `$` + keyword 23 | - or some other sigil 24 | - How important is to to worry about and fix this? 25 | - Could do it as part of a macros 2.0 push 26 | - This could be readily addressed in parallel though with the more weighty macro issues 27 | - but we're spending meeting time and so forth 28 | - Alternative syntax (e.g., `$$crate`) has the advantage of not requiring an edition 29 | - Option: 30 | - Rule out identifiers and limit options to: 31 | - incorporate into macros 2.0 32 | - alternative syntax 33 | - or consider for 2024 if still a live issue 34 | 35 | 36 | ## Project board review 37 | 38 | Review the [Lang team project board](https://github.com/rust-lang/lang-team/projects/2) and get updates 39 | 40 | ## Nominated RFCs 41 | - No nominated RFCs this time. 42 | 43 | ## P-high issues on rust-lang/rust 44 | - "New "warning incompatible with previous forbid in same scope" error" [rust#77713](https://github.com/rust-lang/rust/issues/77713) 45 | 46 | ## Nominated PRs and issues on rust-lang/rust 47 | - "Tracking issue for RFC 2535, 2530, 2175, "Or patterns, i.e `Foo(Bar(x) | Baz(x))`"" [rust#54883](https://github.com/rust-lang/rust/issues/54883) 48 | - "Switch `mutable_borrow_reservation_conflict` lint to deny by default" [rust#76104](https://github.com/rust-lang/rust/pull/76104) 49 | - "Add built-in implementations of `Default` for function definition and…" [rust#77688](https://github.com/rust-lang/rust/pull/77688) 50 | - several members leaning against 51 | - new capability (call without an instance), not obvious that it's a correct capability 52 | - conversations have maybe made folks feel less good about copy/clone, adding more not obviously good 53 | - permits `FnOnce` to be called more than once (if cloned) 54 | - though would require a bound, modulo specialization 55 | - is a PR the right venue? 56 | - it feels like it may want to be an RFC, given the complexity and controversy 57 | - related to safe transmute, the concern is "if you can't call the function normally, why should its type let you call it" 58 | - potential workarounds exist using unsafe code but it's complex, potentially leads to runtime errors 59 | - would like to see a design note 60 | - Josh to write something 61 | - "clarify rules for ZST Boxes" [rust#77844](https://github.com/rust-lang/rust/pull/77844) 62 | - niko in conversation with ralf 63 | - "Support `pub` on `macro_rules`" [rust#78166](https://github.com/rust-lang/rust/pull/78166) 64 | - would still like to see an RFC -Niko 65 | - would we want "no visibility equals old behavior, pub equals new behavior", or do we want a cleaner transition (e.g., in a new edition) 66 | - how much is that an implementation challenge, and who is signing up for it? 67 | - presumably you can replace `foo!` with `super::foo!` in most cases, or `crate::path::foo!` 68 | - conclusion: ping petrochenkov to ask about this -- Mark to write comment 69 | - Mark may be interested in helping 70 | - what are the conditions in which we'd want to land? 71 | - Niko: I'd be happy to land if this was part of some active group pursuing the design we want 72 | - "Rename `overlapping_patterns` lint" [rust#78242](https://github.com/rust-lang/rust/pull/78242) 73 | - Niko to rfcbot fcp merge 74 | - "remove this weird special case from promotion" [rust#78363](https://github.com/rust-lang/rust/pull/78363) 75 | - in pre-fcp 76 | - "Apply `unused_doc_comments` lint to inner items" [rust#78367](https://github.com/rust-lang/rust/pull/78367) 77 | - Niko to leave comment to suggest closing 78 | - "[librustdoc] Only split lang string on `,`, ` `, and `\t`" [rust#78429](https://github.com/rust-lang/rust/pull/78429) 79 | - check your boxes 80 | - "Add #[must_bind] attribute and lint" [rust#78715](https://github.com/rust-lang/rust/pull/78715) 81 | - alternative: lint against `let _ = X` and suggest `drop(X)`, or perhaps change behavior of `let _ = x` to be equivalent to `let _y = x` 82 | - but still accept `let (_, x) = y` and have `_` in this context mean "ignore the first element" 83 | - `#[must_use]` lint presently suggests `let _ = ` as a way to disable the lint 84 | - `let _ = foo();` 85 | - `let (_, _) = foo();` 86 | - when do tuple subelements drop? 87 | - also end of block 88 | - to implement: 89 | - this would be a change of the temporary lifetime rules, related in that way to RFC 66 90 | - Mark to leave comment and summarize 91 | - "Accept arbitrary expressions in key-value attributes at parse time" [rust#78837](https://github.com/rust-lang/rust/pull/78837) 92 | - "Use true previous lint level when detecting overriden forbids" [rust#78864](https://github.com/rust-lang/rust/pull/78864) 93 | - kick off FCP 94 | - "passes: prohibit attrs on generic params" [rust#79073](https://github.com/rust-lang/rust/pull/79073) 95 | - treat the same as the last PR that proposed a similar change 96 | - next step: crater run 97 | - niko to kick off -------------------------------------------------------------------------------- /minutes/2020-12-01.md: -------------------------------------------------------------------------------- 1 | # T-lang meeting agenda 2 | 3 | * Meeting date: 2020-12-01 4 | * [Watch the recording](https://youtu.be/l71JwIW2poA) 5 | 6 | ## Attendance 7 | 8 | * Team members: Josh, Felix, Scott, Niko 9 | * Others: simulacrum, Alex, lcnr 10 | 11 | ## Before meeting checklist 12 | 13 | * [ ] Update the project board with new proposals 14 | * [ ] Update the project board with new RFCs 15 | 16 | ## Pending proposals 17 | - "Add a `NOOP_METHOD_CALL` lint for methods which should never be directly called" [lang-team#67](https://github.com/rust-lang/lang-team/issues/67) 18 | - plan to close today 19 | - "Stop ignoring trailing semicolons in a macro body when a macro is invoked in expression position" [lang-team#70](https://github.com/rust-lang/lang-team/issues/70) 20 | - pnkfelix willing to serve as liaison 21 | 22 | ## Project board review 23 | 24 | Review the [Lang team project board](https://github.com/rust-lang/lang-team/projects/2) and get updates 25 | 26 | ## Nominated RFCs 27 | - "RFC: Checking conditional compilation at compile time" [rfcs#3013](https://github.com/rust-lang/rfcs/pull/3013) 28 | - this is ready for FCP, according to RFC authors 29 | - tracks the set of valid cfg features etc so that we can give warnings for typos 30 | - only tangentially lang, it's mostly a "quality of implementation" concern as lang semantics are not changed 31 | - conclusion: lang is generally in favor of this, willing to remove T-lang and leave the details to cargo/compiler, scottmcm to comment 32 | - "Adds `must_not_await_lint` RFC" [rfcs#3014](https://github.com/rust-lang/rfcs/pull/3014) 33 | - conclusion: 34 | - niko to issue fcp, modulo bikeshed 35 | - bikeshed can be resolved in appropriate zulip stream e.g. #wg-async-foundations 36 | 37 | ## P-high issues on rust-lang/rust 38 | - "New "warning incompatible with previous forbid in same scope" error" [rust#77713](https://github.com/rust-lang/rust/issues/77713) 39 | - check boxes on https://github.com/rust-lang/rust/pull/78864 -- cramertj, withoutboats, joshtriplett 40 | 41 | ## Nominated PRs and issues on rust-lang/rust 42 | - "expand/resolve: Turn `#[derive]` into a regular macro attribute" [rust#79078](https://github.com/rust-lang/rust/pull/79078) 43 | - some backwards incompatibilities 44 | - `derive(Copy, Clone)` optimization may be affected 45 | - Question about: "For historical reasons `#[derive]` fully configures its input, eagerly evaluating cfg everywhere in its target, for example on fields." 46 | - is this new behavior? 47 | - Perf impact? 48 | - Josh to move to FCP, kick off rustc-perf run, cc libs team because it's part of prelude 49 | - "Add built-in implementations of `Default` for function definition and…" [rust#77688](https://github.com/rust-lang/rust/pull/77688) 50 | - waiting on checkboxes 51 | - "Support `pub` on `macro_rules`" [rust#78166](https://github.com/rust-lang/rust/pull/78166) 52 | - still want this to be part of a plan 53 | - the issue of how to transition `macro_rules` with no qualifier (so as to make it equivalent to `pub(self)`) 54 | - there is reluctance to stabilize `pub macro_rules` unless the default behavior is also changed, at least in a new edition 55 | - could e.g. change behavior of `pub macro_rules` in earlier editions but just have the behavior of `macro_rules` with no qualifier change in Rust 2021 56 | - may need to do this for edition purposes 57 | - "Rename `overlapping_patterns` lint" [rust#78242](https://github.com/rust-lang/rust/pull/78242) 58 | - [check your boxes](https://github.com/rust-lang/rust/pull/78242#issuecomment-730176176) 59 | - "Apply `unused_doc_comments` lint to inner items" [rust#78367](https://github.com/rust-lang/rust/pull/78367) 60 | - Niko to fcp close 61 | - "Add #[must_bind] attribute and lint" [rust#78715](https://github.com/rust-lang/rust/pull/78715) 62 | - Follow up regarding what docs are needed to do to get started 63 | - "Accept arbitrary expressions in key-value attributes at parse time" [rust#78837](https://github.com/rust-lang/rust/pull/78837) 64 | - Question: feature-gate? exposed to proc-macros perhaps? 65 | - Expansion order for macro usages, is that exposed to procedural macros? 66 | - Perhaps interaction with name resolution and hygiene (what does `foo::bar` mean) 67 | - Niko to post question about how stable this becomes 68 | - "passes: prohibit attrs on generic params" [rust#79073](https://github.com/rust-lang/rust/pull/79073) 69 | - crater run found no regressions 70 | - pnkfelix to fcp merge 71 | - "Acknowledge that `[CONST; N]` is stable" [rust#79270](https://github.com/rust-lang/rust/pull/79270) 72 | - scott to fcp merge 73 | - "conditional fallback for the `!` type" [rust#79366](https://github.com/rust-lang/rust/pull/79366) 74 | - Niko explains the idea 75 | - `Err(22)?` -- the ok type defaults to `()` unit today 76 | - "Add unstable #[may_ignore] attribute to cancel #[must_use]" [rust#79572](https://github.com/rust-lang/rust/pull/79572) 77 | -------------------------------------------------------------------------------- /minutes/2021-01-12.md: -------------------------------------------------------------------------------- 1 | # T-lang meeting agenda 2 | 3 | * Meeting date: 2021-01-12 4 | * [Watch the recording](https://youtu.be/4dRVeTn5-jQ) 5 | 6 | ## Attendance 7 | 8 | * Team members: nikomatsakis, josh, scott, felix 9 | * Others: simulacrum 10 | 11 | ## Before meeting checklist 12 | 13 | * [ ] Update the project board with new proposals 14 | * [ ] Update the project board with new RFCs 15 | 16 | ## Pending proposals 17 | - "Stop ignoring trailing semicolons in a macro body when a macro is invoked in expression position" [lang-team#70](https://github.com/rust-lang/lang-team/issues/70) 18 | 19 | ## Project board review 20 | 21 | Review the [Lang team project board](https://github.com/rust-lang/lang-team/projects/2) and get updates 22 | 23 | ## Upcoming design meetings 24 | 25 | * : rfcs#3058 (try trait) 26 | * week from tomorrow: 27 | [#73](https://github.com/rust-lang/lang-team/issues/73) will be scheduled next week. 28 | 29 | ## Nominated RFCs 30 | 31 | - "try_trait_v2: A new design for the ? desugaring" [rfcs#3058](https://github.com/rust-lang/rfcs/pull/3058) 32 | - Primarily for discussion in design meeting, but can do brief overview in this meeting. 33 | - Overview: 34 | - Trying to address feedback from the tracking issue 35 | - Extension to keep the '`Option`-ness' or '`Result`-ness', but can't be used for the default `?` desugaring (could be used for try block) 36 | - Lets trait implementations determine whether or where to do `From` conversion 37 | - Hybrid of the various options 38 | 39 | ## P-high issues on rust-lang/rust 40 | - No P-high issues this time. 41 | 42 | ## Nominated PRs and issues on rust-lang/rust 43 | - "Tracking issue for RFC 2535, 2530, 2175, "Or patterns, i.e `Foo(Bar(x) | Baz(x))`"" [rust#54883](https://github.com/rust-lang/rust/issues/54883) 44 | - Appears that we have resolved pat2018/pat2021 matchers 45 | - What do we need for this to be done? 46 | - Stabilization report is missing 47 | - Some form of migration lint for 2021 Edition 48 | - Do we want to block stabilizing on having the migration available? 49 | - Do we even *want* the migration? 50 | - Or is the change insufficiently invasive? 51 | - Concern: if you move a crate with public macros, you may not realize your dependencies are affected 52 | - Sufficient to block on someone saying that a lint is *feasible*? 53 | - Niko to message mark-i-m about stabilization report and matcher 54 | - Avoid stabilizing pat2018/pat2021 until edition 2021 is in place, just in case we will slip or something else 55 | - "Support `pub` on `macro_rules`" [rust#78166](https://github.com/rust-lang/rust/pull/78166) 56 | - Josh and Niko were reaching out, trying to find someone to help do the language side of this 57 | - "expand/resolve: Turn `#[derive]` into a regular macro attribute" [rust#79078](https://github.com/rust-lang/rust/pull/79078) 58 | - cramertj left a comment, petrochenkov asked about status 59 | - waiting on petrochenkov to implement the reordering restriction 60 | - mark to leave a comment with an update 61 | - ""!" is the only type that is unsafe to raw-ptr-deref into a "_" pattern" [rust#79735](https://github.com/rust-lang/rust/issues/79735) 62 | - pnkfelix was looking into having 'syntactic' checking for `unsafe` usage 63 | - turns out that `let _: T = ...` does check for unsafe 64 | - "type ascription" is treated as a use 65 | - `let x: &i32; let _ = *x;` <-- this compiles 66 | - `let x: &i32; let _: i32 = *x;` [also compiles](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7d9edc3e8efc900f282d4028a5dba610) 67 | - for extra fun: `let x: &_; let _: i32 = *x;` 68 | - `let mut x = 22; let y = &mut x; let _ = x; drop(y);` 69 | - consenus from meeting: 70 | - this is a bug, we expect unsafe checking to be "syntactically scoped" 71 | - compiler team can decide the appropriate remedy (niko has opinions) 72 | - interactions with initialization and borrow checking however are not bugs (as described in #79735) 73 | - "Unsafe checking skips pointer dereferences in unused places" [rust#80059](https://github.com/rust-lang/rust/issues/80059) 74 | - this is covered above 75 | - "Allow qualified paths in struct construction (both expressions and patterns)" [rust#80080](https://github.com/rust-lang/rust/pull/80080) 76 | - Request someone to write a summary comment of precisely the new behavior (mini stabilization report) 77 | - Otherwise ready to fcp merge 78 | - Mark to make this request on PR 79 | - "make const_err a future incompat lint" [rust#80394](https://github.com/rust-lang/rust/pull/80394) 80 | - Mark to prepare a summary of how this fits into promotion and other in-flight changes, post on PR, we will revisit next week 81 | - e.g., is this part of the implementation work for https://github.com/rust-lang/rfcs/pull/3027 ? 82 | - "avoid promoting division, modulo and indexing operations that could fail" [rust#80579](https://github.com/rust-lang/rust/pull/80579) 83 | - fixes one of the problems that #80394 would introduce if we were to land it 84 | - crater run was executed with [6 regressions](https://github.com/rust-lang/rust/pull/80579#issuecomment-755459386), and those regression have since been fixed (by backing out the float part of this, as well as array indexing) 85 | - meeting consensus: 86 | - land it 87 | - Niko to post comment 88 | - "relax adt unsizing requirements" [rust#80726](https://github.com/rust-lang/rust/pull/80726) 89 | - Request description of exactly what the new mechanic is and if there are use cases, examples, or other motivation. 90 | - Josh to write a comment. -------------------------------------------------------------------------------- /minutes/2021-01-19.md: -------------------------------------------------------------------------------- 1 | # T-lang meeting agenda 2 | 3 | * Meeting date: 2021-01-19 4 | 5 | ## Attendance 6 | 7 | * Team members: Josh, pnkfelix, scottmcm 8 | * Others: simulacrum, mara, oliver 9 | 10 | ## Before meeting checklist 11 | 12 | * [ ] Update the project board with new proposals 13 | * [ ] Update the project board with new RFCs 14 | 15 | ## Pending proposals 16 | - "Stop ignoring trailing semicolons in a macro body when a macro is invoked in expression position" [lang-team#70](https://github.com/rust-lang/lang-team/issues/70) 17 | - "MCP: Deref Patterns" [lang-team#77](https://github.com/rust-lang/lang-team/issues/77) 18 | 19 | ## Project board review 20 | 21 | Review the [Lang team project board](https://github.com/rust-lang/lang-team/projects/2) and get updates 22 | - RFC 2229: https://hackmd.io/wPs-tHJZR1Cj9j_vwsxwbw?view 23 | 24 | ## Nominated RFCs 25 | - No nominated RFCs this time. 26 | 27 | ## P-high issues on rust-lang/rust 28 | - "regression 1.50: deny after forbid breaks build" [rust#80988](https://github.com/rust-lang/rust/issues/80988) 29 | 30 | ## Nominated PRs and issues on rust-lang/rust 31 | - "expand/resolve: Turn `#[derive]` into a regular macro attribute" [rust#79078](https://github.com/rust-lang/rust/pull/79078) 32 | - "Tracking issue for RFC 2535, 2530, 2175, "Or patterns, i.e `Foo(Bar(x) | Baz(x))`"" [rust#54883](https://github.com/rust-lang/rust/issues/54883) 33 | - Awaiting stabilization report. 34 | - ""!" is the only type that is unsafe to raw-ptr-deref into a "_" pattern" [rust#79735](https://github.com/rust-lang/rust/issues/79735) 35 | - "Unsafe checking skips pointer dereferences in unused places" [rust#80059](https://github.com/rust-lang/rust/issues/80059) 36 | - "Promote 2018 warn lints to deny in Rust 2021" [rust#80165](https://github.com/rust-lang/rust/issues/80165) 37 | 38 | ----- 39 | These nominated items were not covered in this week's meeting: 40 | 41 | - "make const_err a future incompat lint" [rust#80394](https://github.com/rust-lang/rust/pull/80394) 42 | - "avoid promoting division, modulo and indexing operations that could fail" [rust#80579](https://github.com/rust-lang/rust/pull/80579) 43 | - "don't gratuitously error on tests returning Result with lifetime" [rust#80934](https://github.com/rust-lang/rust/pull/80934) 44 | - "Stabilize remaining integer methods as `const fn`" [rust#80962](https://github.com/rust-lang/rust/pull/80962) 45 | - "regression 1.50: deny after forbid breaks build" [rust#80988](https://github.com/rust-lang/rust/issues/80988) 46 | -------------------------------------------------------------------------------- /minutes/2021-10-19.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Triage meeting 2021-10-19 3 | tags: triage-meeting 4 | --- 5 | 6 | # T-lang meeting agenda 7 | 8 | * Meeting date: 2021-10-19 9 | 10 | ## Attendance 11 | 12 | * Team members: Niko, Taylor, Felix 13 | * Others: Mark 14 | 15 | ## Meeting roles 16 | 17 | * Action item scribe: simulacrum 18 | * Note-taker: Niko 19 | 20 | ## Scheduled meetings 21 | - Tomorrow: "Dyn upcasting, safety considerations" [lang-team#119](https://github.com/rust-lang/lang-team/issues/119) 22 | - On Zulip! 23 | - "Never allow unwinding from Drop impls" [lang-team#97](https://github.com/rust-lang/lang-team/issues/97) 24 | 25 | ## Announcements or custom items 26 | 27 | (Meeting attendees, feel free to add items here!) 28 | 29 | * Mark: ~const stuff 30 | * Do we have a good understanding of this design? 31 | * e.g., https://github.com/rust-lang/rust/pull/86840 is adding a bunch of const impls 32 | * there's also https://doc.rust-lang.org/nightly/core/intrinsics/fn.const_eval_select.html which is interesting 33 | 34 | ## Action item review 35 | 36 | * [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A) 37 | 38 | ## Pending lang team project proposals 39 | 40 | ### "negative impls integrated into coherence" lang-team#96 41 | 42 | **Link:** https://github.com/rust-lang/lang-team/issues/96 43 | 44 | * scottmcm as liaison 45 | 46 | ### "Deprecate target_vendor " lang-team#102 47 | 48 | **Link:** https://github.com/rust-lang/lang-team/issues/102 49 | 50 | ### "Async fundamentals initiative" lang-team#116 51 | 52 | **Link:** https://github.com/rust-lang/lang-team/issues/116 53 | 54 | * nikomatsakis or maybe cramertj as liaison 55 | 56 | ### "Attribute for trusted external static declarations" lang-team#118 57 | 58 | **Link:** https://github.com/rust-lang/lang-team/issues/118 59 | 60 | ### "Prototype Sync & Async Iterator Items (Minimal generators)" lang-team#121 61 | 62 | **Link:** https://github.com/rust-lang/lang-team/issues/121 63 | 64 | * pnkfelix as liaison 65 | 66 | ### "Enum Variant Types" lang-team#122 67 | 68 | **Link:** https://github.com/rust-lang/lang-team/issues/122 69 | 70 | * Most people are in favor of this general direction 71 | * Is it a good thing to do now and does someone have time to see it through? 72 | 73 | ## PRs on the lang-team repo 74 | ### "Initial draft of copy ergonomics design note" lang-team#62 75 | 76 | **Link:** https://github.com/rust-lang/lang-team/pull/62 77 | 78 | * Mark to update this with a "maybe incomplete see ...comment..." disclaimer, bug someone to merge 79 | * maybe just merge them with a link to follow-up? 80 | 81 | ### "Add draft of variadic notes" lang-team#76 82 | 83 | **Link:** https://github.com/rust-lang/lang-team/pull/76 84 | 85 | * Mark to update this with a "maybe incomplete see ...comment..." disclaimer, bug someone to merge 86 | * maybe just merge them with a link to follow-up? 87 | 88 | ### "consensus decision making" lang-team#113 89 | 90 | **Link:** https://github.com/rust-lang/lang-team/pull/113 91 | 92 | * pnkfelix left a review 93 | * josh needs to respond 94 | 95 | ## RFCs waiting to be merged 96 | 97 | None. 98 | 99 | 100 | 101 | 102 | ## Proposed FCPs 103 | 104 | **Check your boxes!** 105 | 106 | ### "Constrained Naked Functions" rfcs#2972 107 | 108 | **Link:** https://github.com/rust-lang/rfcs/pull/2972 109 | 110 | ### "RFC: Add `target` configuration" rfcs#2991 111 | 112 | **Link:** https://github.com/rust-lang/rfcs/pull/2991 113 | 114 | * niko has pending action item 115 | 116 | ### "Tracking Issue for `destructuring_assignment`" rust#71126 117 | 118 | **Link:** https://github.com/rust-lang/rust/issues/71126 119 | 120 | * [stabilization report](https://github.com/rust-lang/rust/issues/71126#issuecomment-941148058) 121 | 122 | ### "Tracking issue for `#![feature(const_precise_live_drops)]`" rust#73255 123 | 124 | **Link:** https://github.com/rust-lang/rust/issues/73255 125 | 126 | * [stabilization report](https://github.com/rust-lang/rust/issues/73255#issuecomment-938086246) 127 | * [cramertj points out that we don't have any docs on this](https://github.com/rust-lang/rust/issues/73255#issuecomment-942783781) 128 | 129 | ### "Tracking Issue for relaxed struct unsizing rules" rust#81793 130 | 131 | **Link:** https://github.com/rust-lang/rust/issues/81793 132 | 133 | ### "Tracking Issue for const-initialized thread locals" rust#84223 134 | 135 | **Link:** https://github.com/rust-lang/rust/issues/84223 136 | 137 | ### "Port clippy lint `redundant_field_names` to compiler" rust#87512 138 | 139 | **Link:** https://github.com/rust-lang/rust/pull/87512 140 | 141 | * FCP to close 142 | 143 | ## Active FCPs 144 | ### "negative impls integrated into coherence" lang-team#96 145 | 146 | **Link:** https://github.com/rust-lang/lang-team/issues/96 147 | 148 | 149 | 150 | ## P-critical issues 151 | 152 | None. 153 | 154 | 155 | 156 | 157 | ## Nominated RFCs, PRs and issues 158 | ### "Tracking Issue for const-initialized thread locals" rust#84223 159 | 160 | **Link:** https://github.com/rust-lang/rust/issues/84223 161 | 162 | ### "Stabilize built-in attribute macro `#[cfg_eval]`" rust#87221 163 | 164 | **Link:** https://github.com/rust-lang/rust/pull/87221 165 | 166 | ### "Port clippy lint `redundant_field_names` to compiler" rust#87512 167 | 168 | **Link:** https://github.com/rust-lang/rust/pull/87512 169 | 170 | ### "Which patterns on union fields should be considered safe?" rust#87520 171 | 172 | **Link:** https://github.com/rust-lang/rust/issues/87520 173 | 174 | ### "Stabilize `const_raw_ptr_deref` for `*const T`" rust#89551 175 | 176 | **Link:** https://github.com/rust-lang/rust/pull/89551 177 | 178 | ### "warn on must_use use on async fn's" rust#89610 179 | 180 | **Link:** https://github.com/rust-lang/rust/pull/89610 181 | 182 | Mark to write a comment saying lang team has no objection to adding this warning until such time as `#[must_use]` on an async function works (if ever). 183 | 184 | ### "Re-enable debug checks in `copy[_nonoverlapping]`" rust#90012 185 | 186 | **Link:** https://github.com/rust-lang/rust/issues/90012 187 | 188 | Discussed and left a comment. General feeling is that this is a "best effort" check and it's ok to go forward, but we were not clear on the overall limits of the extent to which miri can check this. 189 | -------------------------------------------------------------------------------- /minutes/2022-01-04.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Triage meeting 2022-01-11 3 | tags: triage-meeting 4 | --- 5 | 6 | # T-lang meeting agenda 7 | 8 | * Meeting date: 2022-01-11 9 | 10 | ## Attendance 11 | 12 | * Team members: Josh, Taylor, Felix 13 | * Others: Mark, Mara 14 | 15 | ## Meeting roles 16 | 17 | * Action item scribe: simulacrum 18 | * Note-taker: 19 | 20 | ## Scheduled meetings 21 | - Enum discriminants and casting, planned for January 12, jswrenn prepared some work for this 22 | - doc: https://hackmd.io/FejspdTdSX-xaPrcFc5W9w?both 23 | - How does https://github.com/rust-lang/rust/pull/81642 (`AsRepr`/`FromRepr`) fit into this broader story? 24 | 25 | - "Structural equality" [lang-team#94](https://github.com/rust-lang/lang-team/issues/94) 26 | - "Never allow unwinding from Drop impls" [lang-team#97](https://github.com/rust-lang/lang-team/issues/97) 27 | - "Dyn upcasting, safety considerations" [lang-team#119](https://github.com/rust-lang/lang-team/issues/119) 28 | - "Const eval overview" [lang-team#131](https://github.com/rust-lang/lang-team/issues/131) 29 | 30 | ## Announcements or custom items 31 | 32 | 33 | 34 | ## Initiative check-in: never type 35 | 36 | ## Summary 37 | 38 | * Work has started on inlining problems/evaluations from issues, gists, etc. 39 | See [no inference changes](https://rust-lang.github.io/never-type-initiative/evaluation/no-inference-changes.html), 40 | [PRs/issues](https://rust-lang.github.io/never-type-initiative/evaluation/issues.md); the no inference changes page is likely 41 | mostly complete. Some other pages are also available but in more draft status. 42 | 43 | ## Goals for this month 44 | 45 | * Continue to fill out scenarios, particularly explanations of current 46 | feature-gated state and the effects (breakage, expectations for next steps). 47 | 48 | ## Questions for discussion, meeting proposals 49 | 50 | * No particular all-lang questions yet. Current trajectory suggests that we will 51 | have a complete-ish set of documents for lang review in 1-2 months, depending 52 | on bandwidth. Current expectation is that we have a roughly ready nightly 53 | implementation, but more work is needed to document it and the tradeoffs it 54 | makes. 55 | 56 | Copying from [update](https://rust-lang.github.io/never-type-initiative/updates/2022-01-11.html). 57 | 58 | ## Action item review 59 | 60 | * [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A) 61 | 62 | ## Pending lang team project proposals 63 | ### "Deprecate target_vendor " lang-team#102 64 | 65 | **Link:** https://github.com/rust-lang/lang-team/issues/102 66 | 67 | ### "Async fundamentals initiative" lang-team#116 68 | 69 | **Link:** https://github.com/rust-lang/lang-team/issues/116 70 | 71 | ### "Attribute for trusted external static declarations" lang-team#118 72 | 73 | **Link:** https://github.com/rust-lang/lang-team/issues/118 74 | 75 | ### "Prototype Sync & Async Iterator Items (Minimal generators)" lang-team#121 76 | 77 | **Link:** https://github.com/rust-lang/lang-team/issues/121 78 | 79 | ### "Support platforms with size_t != uintptr_t" lang-team#125 80 | 81 | **Link:** https://github.com/rust-lang/lang-team/issues/125 82 | 83 | ### "Positional Associated Types" lang-team#126 84 | 85 | **Link:** https://github.com/rust-lang/lang-team/issues/126 86 | 87 | ### "Heap allocations in constants" lang-team#129 88 | 89 | **Link:** https://github.com/rust-lang/lang-team/issues/129 90 | 91 | ### "Attribute to reverse field destruction order in the drop glue" lang-team#135 92 | 93 | **Link:** https://github.com/rust-lang/lang-team/issues/135 94 | 95 | * No direct objections raised, though some desire to review. 96 | * Scott notes that explicitly indicating current drop order may be useful as well. 97 | 98 | ## PRs on the lang-team repo 99 | 100 | None. 101 | 102 | 103 | 104 | 105 | ## RFCs waiting to be merged 106 | 107 | None. 108 | 109 | 110 | 111 | 112 | ## Proposed FCPs 113 | 114 | **Check your boxes!** 115 | ### "Change location of where clause on GATs" rust#90076 116 | 117 | **Link:** https://github.com/rust-lang/rust/pull/90076 118 | 119 | * Niko and Josh expect to talk about this shortly. 120 | * Parsing both and steering toward one (e.g., via rustfix) may unblock this. 121 | 122 | ## Active FCPs 123 | ### "Positional Associated Types" lang-team#126 124 | 125 | **Link:** https://github.com/rust-lang/lang-team/issues/126 126 | 127 | ### "Attribute to reverse field destruction order in the drop glue" lang-team#135 128 | 129 | **Link:** https://github.com/rust-lang/lang-team/issues/135 130 | 131 | 132 | 133 | ## P-critical issues 134 | 135 | None. 136 | 137 | 138 | 139 | 140 | ## Nominated RFCs, PRs and issues 141 | 142 | ### "impl Not for !" rust#91122 143 | 144 | **Link:** https://github.com/rust-lang/rust/pull/91122 145 | 146 | - Open question: does lang need to approve, or be consulted, on new impls of traits for `!`? 147 | - Conclusion: no, but consult Mark (owner for `!`) if there are any doubts 148 | - Please use caution for anything with associated types 149 | - In particular, must never have a method that doesn't take self but returns Self, because that would allow constructing a `!`. 150 | - Also use caution for binary operator traits, because they may cause inference issues (wouldn't be possible anyway due to overlap) 151 | 152 | ### "Tracking issue for `#![register_tool]`" rust#66079 153 | 154 | **Link:** https://github.com/rust-lang/rust/issues/66079 155 | 156 | * Is the expectation that clippy, rustdoc, rustfmt are going to be added as registered tools in ~all crates? 157 | * rustfmt and clippy are hardcoded in the compiler 158 | * Want to be able to introduce new tools without hardcoding them in the compiler 159 | * -------------------------------------------------------------------------------- /projects/README.md: -------------------------------------------------------------------------------- 1 | This directory contains the "charters" for various projects that we 2 | are undertaking. 3 | -------------------------------------------------------------------------------- /projects/const-generics.md: -------------------------------------------------------------------------------- 1 | # const generics 2 | 3 | ## Summary and problem statement 4 | 5 | Implement and design the `const_generics` feature with 6 | the initial goal of stabilizing the `min_const_generics` subset. 7 | 8 | ## Prioritization 9 | 10 | This project group will pretty much directly work on the third highest [lang team priority] by trying to support const generics on stable. 11 | 12 | [lang team priority]: https://lang-team.rust-lang.org/priorities.html 13 | 14 | ## Motivation, use-cases, and solution sketches 15 | 16 | Const generics allows us to to parameterized types by values. Most noticably 17 | this allows us to abstract over array lengths. 18 | 19 | The initial goal is to stabilize `min_const_generics` in a way which is both usable 20 | while preventing any future developments. 21 | 22 | To do so we will impose two restrictions on const generics: 23 | 24 | - They can only have the type of an integral primitive type (integers, `bool`, and `char`). 25 | - Expressions used in const generic position must be either: 26 | - Just a const generic name in scope (e.g. `N`) 27 | - A const expression which contains on no free type or const parameters. 28 | 29 | There are also some additional concerns which require attention before stabilizion `min_const_generics`, most of which are hopefully minor. 30 | 31 | The currently most interesting problems after `min_const_generics` is how to assert 32 | the well-formedness of const generics and how to introduce lazy normalization. 33 | 34 | ## Links and related work 35 | 36 | - [original RFC](https://github.com/rust-lang/rfcs/pull/2000) 37 | - [`min_const_generics` compiler MCP](https://github.com/rust-lang/compiler-team/issues/332) 38 | - [`min_const_generics` tracking issue](https://github.com/rust-lang/rust/issues/74878) 39 | - [lang team meeting](https://github.com/rust-lang/lang-team/issues/37) 40 | 41 | ## Initial people involved 42 | 43 | *List the lang-team liaison who picked up the proposal along with the project group lead(s) and any other folks who would like to participate in some capacity. If you have some idea who might implement the idea, that's good to list too.* 44 | 45 | -------------------------------------------------------------------------------- /projects/declarative-macro-repetition-counts/0000-draft-rfc.md: -------------------------------------------------------------------------------- 1 | - Feature Name: (fill me in with a unique ident, `my_awesome_feature`) 2 | - Start Date: (fill me in with today's date, YYYY-MM-DD) 3 | - RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000) 4 | - Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000) 5 | 6 | # Summary 7 | [summary]: #summary 8 | 9 | One paragraph explanation of the feature. 10 | 11 | # Motivation 12 | [motivation]: #motivation 13 | 14 | Why are we doing this? What use cases does it support? What is the expected outcome? 15 | 16 | # Guide-level explanation 17 | [guide-level-explanation]: #guide-level-explanation 18 | 19 | Explain the proposal as if it was already included in the language and you were teaching it to another Rust programmer. That generally means: 20 | 21 | - Introducing new named concepts. 22 | - Explaining the feature largely in terms of examples. 23 | - Explaining how Rust programmers should *think* about the feature, and how it should impact the way they use Rust. It should explain the impact as concretely as possible. 24 | - If applicable, provide sample error messages, deprecation warnings, or migration guidance. 25 | - If applicable, describe the differences between teaching this to existing Rust programmers and new Rust programmers. 26 | 27 | For implementation-oriented RFCs (e.g. for compiler internals), this section should focus on how compiler contributors should think about the change, and give examples of its concrete impact. For policy RFCs, this section should provide an example-driven introduction to the policy, and explain its impact in concrete terms. 28 | 29 | # Reference-level explanation 30 | [reference-level-explanation]: #reference-level-explanation 31 | 32 | This is the technical portion of the RFC. Explain the design in sufficient detail that: 33 | 34 | - Its interaction with other features is clear. 35 | - It is reasonably clear how the feature would be implemented. 36 | - Corner cases are dissected by example. 37 | 38 | The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. 39 | 40 | # Drawbacks 41 | [drawbacks]: #drawbacks 42 | 43 | Why should we *not* do this? 44 | 45 | # Rationale and alternatives 46 | [rationale-and-alternatives]: #rationale-and-alternatives 47 | 48 | - Why is this design the best in the space of possible designs? 49 | - What other designs have been considered and what is the rationale for not choosing them? 50 | - What is the impact of not doing this? 51 | 52 | # Prior art 53 | [prior-art]: #prior-art 54 | 55 | Discuss prior art, both the good and the bad, in relation to this proposal. 56 | A few examples of what this can include are: 57 | 58 | - For language, library, cargo, tools, and compiler proposals: Does this feature exist in other programming languages and what experience have their community had? 59 | - For community proposals: Is this done by some other community and what were their experiences with it? 60 | - For other teams: What lessons can we learn from what other communities have done here? 61 | - Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. 62 | 63 | This section is intended to encourage you as an author to think about the lessons from other languages, provide readers of your RFC with a fuller picture. 64 | If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other languages. 65 | 66 | Note that while precedent set by other languages is some motivation, it does not on its own motivate an RFC. 67 | Please also take into consideration that rust sometimes intentionally diverges from common language features. 68 | 69 | # Unresolved questions 70 | [unresolved-questions]: #unresolved-questions 71 | 72 | - What parts of the design do you expect to resolve through the RFC process before this gets merged? 73 | - What parts of the design do you expect to resolve through the implementation of this feature before stabilization? 74 | - What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? 75 | 76 | # Future possibilities 77 | [future-possibilities]: #future-possibilities 78 | 79 | Think about what the natural extension and evolution of your proposal would 80 | be and how it would affect the language and project as a whole in a holistic 81 | way. Try to use this section as a tool to more fully consider all possible 82 | interactions with the project and language in your proposal. 83 | Also consider how the this all fits into the roadmap for the project 84 | and of the relevant sub-team. 85 | 86 | This is also a good place to "dump ideas", if they are out of scope for the 87 | RFC you are writing but otherwise related. 88 | 89 | If you have tried and cannot think of any future possibilities, 90 | you may simply state that you cannot think of anything. 91 | 92 | Note that having something written down in the future-possibilities section 93 | is not a reason to accept the current or a future RFC; such notes should be 94 | in the section on motivation or rationale in this or subsequent RFCs. 95 | The section merely provides additional information. 96 | -------------------------------------------------------------------------------- /projects/declarative-macro-repetition-counts/charter.md: -------------------------------------------------------------------------------- 1 | # Declarative macro repetition counts 2 | 3 | ## Summary and problem statement 4 | 5 | Add new syntax to allow declarative macro authors to easily access the count 6 | or index of declarative macro repetitions. 7 | 8 | ## Prioritization 9 | 10 | This project fits in the "Targeted ergonomic wins and extensions" category. 11 | 12 | ## Motivation, use-cases, and solution sketches 13 | 14 | Macros with repetitions often expand to code that needs to know or could 15 | benefit from knowing how many repetitions there are, or which repetition is 16 | currently being expanded. Consider the standard sample macro to create a 17 | vector, recreating the standard library `vec!` macro: 18 | 19 | ``` 20 | macro_rules! myvec { 21 | ($($value:expr),* $(,)?) => { 22 | { 23 | let mut v = Vec::new(); 24 | $( 25 | v.push($value); 26 | )* 27 | v 28 | } 29 | }; 30 | } 31 | ``` 32 | 33 | This would be more efficient if it could use `Vec::with_capacity` to 34 | preallocate the vector with the correct length. However, there is no standard 35 | facility in declarative macros to achieve this. 36 | 37 | There are various ways to work around this limitation. Some common approaches 38 | that users take are listed below, along with some of their drawbacks. 39 | 40 | ### Use recursion 41 | 42 | Use a recursive macro to calculate the length. 43 | 44 | ``` 45 | macro_rules! count_exprs { 46 | () => {0usize}; 47 | ($head:expr, $($tail:expr,)*) => {1usize + count_exprs!($($tail,)*)}; 48 | } 49 | 50 | macro_rules! myvec { 51 | ($(value:expr),* $(,)?) => { 52 | { 53 | let size = count_exprs!($($value,)*); 54 | let mut v = Vec::with_capacity(size); 55 | $( 56 | v.push($value); 57 | )* 58 | v 59 | } 60 | }; 61 | } 62 | ``` 63 | 64 | Whilst this is among the first approaches that a novice macro programmer 65 | might take, it is also the worst performing. It rapidly hits the recursion 66 | limit, and if the recursion limit is raised, it takes more than 25 seconds to 67 | compile a sequence of 2,000 items. Sequences of 10,000 items can crash 68 | the compiler with a stack overflow. 69 | 70 | ### Generate a sum of 1s 71 | 72 | This example is courtesy of @dtolnay. 73 | Create a macro expansion that results in an expression like `0 + 1 + ... + 1`. 74 | There are various ways to do this, but one example is: 75 | 76 | ``` 77 | macro_rules! myvec { 78 | ( $( $value:expr ),* $(,)? ) => { 79 | { 80 | let size = 0 { $( + { stringify!(value); 1 } ) }; 81 | let mut v = Vec::with_capacity(size); 82 | $( 83 | v.push($value); 84 | )* 85 | v 86 | } 87 | }; 88 | } 89 | ``` 90 | 91 | This performs better than recursion, however large numbers of items still 92 | cause problems. It takes nearly 4 seconds to compile a sequence of 2,000 93 | items. Sequences of 10,000 items can still crash the compiler with a stack 94 | overflow. 95 | 96 | ### Generate a slice and take its length 97 | 98 | This example is taken from 99 | [https://danielkeep.github.io/tlborm/book/blk-counting.html]. Create a macro 100 | expansion that results in a slice of the form `[(), (), ... ()]` and take its 101 | length. 102 | 103 | ``` 104 | macro_rules! replace_expr { 105 | ($_t:tt $sub:expr) => {$sub}; 106 | } 107 | 108 | macro_rules! myvec { 109 | ( $( $value:expr ),* $(,)? ) => { 110 | { 111 | let size = <[()]>::len(&[$(replace_expr!(($value) ())),*]); 112 | let mut v = Vec::with_capacity(size); 113 | $( 114 | v.push($value); 115 | )* 116 | v 117 | } 118 | }; 119 | } 120 | ``` 121 | 122 | This is more efficient, taking less than 2 seconds to compile 2,000 items, 123 | and just over 6 seconds to compile 10,000 items. 124 | 125 | ### Discoverability 126 | 127 | Just considering the performance comparisons misses the point. While we 128 | can work around these limitations with carefully crafted macros, for a 129 | developer unfamiliar with the subtleties of macro expansions it is hard 130 | to discover which is the most efficient way. 131 | 132 | Furthermore, whichever method is used, code readability is harmed by the 133 | convoluted expressions involved. 134 | 135 | ### Proposal 136 | 137 | The compiler already knows how many repetitions there are. What is 138 | missing is a way to obtain it. 139 | 140 | We propose to add syntax to allow this to be expressed directly. 141 | 142 | As an initial suggestion, we are considering `${function(...)}` where function 143 | can be `count` or `index`. For example: 144 | 145 | ``` 146 | macro_rules! myvec { 147 | ( $( $value:expr ),* $(,)? ) => { 148 | { 149 | let mut v = Vec::with_capacity(${count(value)}); 150 | $( 151 | v.push($value); 152 | )* 153 | v 154 | } 155 | }; 156 | } 157 | ``` 158 | 159 | In the future this could be used for other things, but anything other than 160 | the repetition count or index are **out of scope** for this project. 161 | 162 | ## Links and related work 163 | 164 | [MCP issue](https://github.com/rust-lang/lang-team/issues/28) 165 | 166 | ## Initial people involved 167 | 168 | Initial people: markbt, Lokathor 169 | 170 | -------------------------------------------------------------------------------- /projects/deref-patterns.md: -------------------------------------------------------------------------------- 1 | # Proposal 2 | 3 | Allow pattern matching through types that impl `Deref` or `DerefMut`. 4 | 5 | ## Summary and problem statement 6 | 7 | Currently in rust, matching is blocked by bounderies like smart pointers, containers, and some wrappers. 8 | To solve this problem you would need to either use if let guards (unstable), or nested match/if-let. 9 | The former is limited to one such level, and the latter can become excessive for deeply nested types. 10 | To solve this, it is proposed propose that "deref patterns" be added, to allow for such matching to be performed. 11 | 12 | An exception to the above problem, is that `Box` can be matched with `feature(box_patterns)`. 13 | However, this is magic behaviour of box, and a goal of this project is to remove or reduce that magic. 14 | 15 | The proposed solution has a number of unanswered questions, including the syntax for patterns, whether or not to limit to standard library types, 16 | and how to allow exhaustive patterns soundly if not limited to standard library types. 17 | 18 | ### Exhaustive Patterns and Soundness 19 | 20 | One current issue with the proposed deref patterns is that if applied generally to any type that implements `Deref`, 21 | it cannot soundly permit exhaustive pattern matching, as a malicious `Deref` impl could return a different value each time. 22 | An trivial example would be `Deref` impl that returns a static reference to an enum value that is chosen randomly 23 | There are currently 3 different possible solutions: 24 | * Do not treat deref patterns as exhausitve 25 | * Restrict deref patterns to (possibly a subset of) standard library types 26 | * Expose an unsafe lang item trait called `DerefPure`, and restrict deref patterns to implementors of that trait 27 | 28 | This initial Project Group will persue the second option, that is limiting deref patterns to a subset of standard library types. Other projects may, in the future, expand upon the work from this project to include user-provided types. The project will determine the critera for a subset needed for sound exhaustive matching, and propose an initial subset to support. 29 | 30 | 31 | ## Motivation, use-cases, and solution sketches 32 | 33 | Recursive types necessarily include smart pointers, even when you could normally match through them. 34 | For example, in a work in progress proc-macro to support restricted variadic generics, the parser needed to match "fold expressions", which take the form `( ...)`. With deref patterns, this could be implemented using `Expr::Paren(ParenExpr{expr: Expr::Binary(ExprBinary{ left, op, right: Expr::Verbatim(t), ..}), ..})`. However, this is currently not possible, and required nested matches. 35 | This generalizes to any case where you need to check some pattern, but hit a deref boundery. 36 | 37 | 38 | 39 | ## Prioritization 40 | 41 | This likely does not fit into any of the listed priorities, though it may be considered "Targeted ergonomic wins and extensions". 42 | 43 | ## Links and related work 44 | 45 | This has been discussed on the Rust Internals Forum at , 46 | as well as on zulip at . 47 | 48 | A tracking document of all currently discussed questions and potential answers can be found here . 49 | 50 | Prior discussions raised on the IRLO thread: 51 | * https://github.com/rust-lang/rfcs/pull/462 52 | * https://github.com/rust-lang/rfcs/issues/2099 53 | * https://github.com/rust-lang/rfcs/blob/master/text/0809-box-and-in-for-stdlib.md 54 | 55 | ## Initial people involved 56 | 57 | Initially, Connor Horman and Nadriel on zulip would be involved 58 | -------------------------------------------------------------------------------- /src/SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | - [Welcome](./welcome.md) 4 | - [How do I...?](./how_to.md) 5 | - [Nominate an issue](./how_to/nominate.md) 6 | - [Request a design meeting](./how_to/design_meeting.md) 7 | - [Propose a change to the language](./how_to/propose.md) 8 | - [Propose or extend a new lint?](./how_to/new_lint.md) 9 | - [Add an experimental feature gate](./how_to/experiment.md) 10 | - [Stabilize a feature](./how_to/stabilize.md) 11 | - [Decision process and principles](./decision_process.md) 12 | - [Decision process examples](./decision_process/examples.md) 13 | - [Decision process reference](./decision_process/reference.md) 14 | - [Becoming and being a lang-team member](./membership.md) 15 | - [Lang-team leads](./leads.md) 16 | - [Chat platform](./chat_platform.md) 17 | - [Calendar](./calendar.md) 18 | - [Meetings](./meetings.md) 19 | - [Triage meeting](./meetings/triage.md) 20 | - [Planning and design meetings](./meetings/design.md) 21 | - [Backlog bonanza](./meetings/backlog-bonanza.md) 22 | - [Frequently Requested Changes](./frequently-requested-changes.md) 23 | - [Design notes](./design_notes.md) 24 | - [Allowing integer literals like `1` to be inferred to floating point](./design_notes/int_literal_as_float.md) 25 | - [Generalizing coroutines](./design_notes/general_coroutines.md) 26 | - [Extending the capabilities of compiler-generated function types](./design_notes/fn_type_trait_impls.md) 27 | - [Auto traits](./design_notes/auto_traits.md) 28 | - [Eager drop](./design_notes/eager_drop.md) 29 | - [Autoderef and autoref in operators](./design_notes/autoref_ops.md) 30 | - [Copy type ergonomics](./design_notes/copy_ergonomics.md) 31 | - [Roadmaps](./roadmaps.md) 32 | - [Roadmap 2024](./roadmaps/roadmap-2024.md) 33 | -------------------------------------------------------------------------------- /src/backlog-bonanza.md: -------------------------------------------------------------------------------- 1 | # Backlog bonanza 2 | -------------------------------------------------------------------------------- /src/calendar.md: -------------------------------------------------------------------------------- 1 | # Calendar 2 | 3 | The lang team has two recurring weekly meeting slots: 4 | 5 | - [Triage meetings](./meetings/triage.html): Weekly on Wednesdays at 11:00 U.S. Eastern Time. 6 | - [Design/planning meetings](./meetings/design.html): Weekly on Wednesdays at 13:00 U.S. Eastern Time. 7 | 8 | When adjusting for other time zones, note that our meeting times follow changes in the particulars of U.S. daylight saving time. 9 | 10 | For the design/planning meeting slot, we typically do a planning meeting on the first Wednesday of the month, then we do design meetings on each remaining Wednesday. 11 | 12 | Our meetings are open to all those who are interested to listen. 13 | 14 | To subscribe to the calendar of our recurring meetings, add this URL to your favorite calendaring application: 15 | 16 | - 17 | 18 | Our schedule of upcoming design meetings is tracked in a GitHub project and can be viewed here: 19 | 20 | - [Design meeting schedule](https://github.com/orgs/rust-lang/projects/31/views/10) 21 | 22 | Each design meeting issue includes details about what we'll be discussing. After the meeting, the issue will include a link to the minutes. 23 | 24 | Minutes for all of our recent meetings can be found here: 25 | 26 | - [Lang team documents on HackMD](https://hackmd.io/@rust-lang-team) 27 | 28 | Periodically, we archive our meeting minutes to git: 29 | 30 | - [Lang team archived minutes](https://github.com/rust-lang/lang-team/tree/master/minutes) 31 | 32 | ## Subteam Calendars 33 | 34 | Some subteams of the lang team reuse the primary lang team calendar for their own calendar events, while others may choose to create a separate calendar. We'll list below the calendars of all subteams that do not use the main calendar. 35 | -------------------------------------------------------------------------------- /src/chat_platform.md: -------------------------------------------------------------------------------- 1 | # Chat platform 2 | 3 | The lang team hangs out in the [rust-lang Zulip] in the `#t-lang` 4 | stream. There are also other `#t-lang/*` streams that might be of 5 | interest. 6 | 7 | [rust-lang Zulip]: https://forge.rust-lang.org/chat/zulip.html 8 | -------------------------------------------------------------------------------- /src/decision_process.md: -------------------------------------------------------------------------------- 1 | This section documents the work-in-progress Rust language team decision 2 | process. This process, and the `rustbot` tooling to support it, does not yet 3 | have a finished implementation. This document serves to explain the intended 4 | process, for the purposes of ongoing implementation. 5 | 6 | ## Prioritized principles of Rust team consensus decision-making 7 | 8 | These are in order of priority. They're intended to be general enough that they 9 | could apply to any Rust governance team, not just the language team. 10 | 11 | - **Treasure dissent.** When someone raises a concern, that's a chance to 12 | improve the design, and to discover and explore underlying values. Dissent 13 | should be an amicable, cooperative process. 14 | - **Understand and cooperatively resolve concerns.** We cannot resolve a 15 | concern without first understanding it, including the underlying values 16 | motivating it. We should demonstrate that understanding by documenting the 17 | concern. We should consider the tradeoffs and the impacts on users, through 18 | the Rust design principles. We should seek out and favor satisfying solutions 19 | (those that satisfy everyone's values) over 20 | [satisficing](https://en.wikipedia.org/wiki/Satisficing) solutions (those 21 | that are just good enough for people to accept them as a compromise among 22 | conflicting values, without actually being happy with the outcome). 23 | - **Don't force an irreversible decision.** We should make decisions 24 | reversible whenever we can. When making a necessarily irreversible decision 25 | (e.g. stabilizing a feature), we should pay close attention to dissent, and 26 | hesitate before overriding objections. If possible, we should seek a better 27 | alternative, or seek common ground we can find consensus on, or seek an 28 | intermediate step that addresses the same use case and supports evaluation 29 | for a more informed decision in the future. If none of those are possible, 30 | consider the null alternative; not making a change should always be the 31 | easier path, and the burden of proof to override a concern on an irreversible 32 | decision should be high. 33 | - **Value expertise.** When cooperatively resolving a concern, or when 34 | considering overriding a concern, carefully weigh the advice and 35 | recommendations of experts. This includes team advisors, domain experts, and 36 | the owners or members of relevant initiatives. 37 | - **Recording reasoning helps ensure good, consistent decisions over time.** 38 | Even if we decide not to sustain an objection, we should always record the 39 | objection and the reasons for our decision as a "dissent", as well as any 40 | unresolved questions for evaluation later in the process. The team member who 41 | raised the objection has the perogative to author that dissent and frame the 42 | unresolved questions (within reason). 43 | - **Consensus doesn't mean unanimity.** Consensus means everyone is heard and 44 | understood, and all concerns are addressed (even those not treated as 45 | blocking), and the team finds the outcome reasonable. Consensus does not mean 46 | everyone agrees completely. 47 | 48 | ## Consensus decision-making process 49 | 50 | First, see [some examples of the decision-making process in 51 | action](./decision_process/examples.md). Then, read the [decision process 52 | reference](./decision_process/reference.md) for the full process and the 53 | `rustbot` tooling to support it. 54 | -------------------------------------------------------------------------------- /src/design-meeting.md: -------------------------------------------------------------------------------- 1 | # Planning and design meetings 2 | -------------------------------------------------------------------------------- /src/design_notes.md: -------------------------------------------------------------------------------- 1 | This section contains "notes" about the design of various proposals. 2 | These are often just links to conversations, along with a few key 3 | ideas and summaries. Sometimes it includes other information, such as 4 | lang-team decisions about whether a particular proposal is viable. 5 | -------------------------------------------------------------------------------- /src/design_notes/auto_traits.md: -------------------------------------------------------------------------------- 1 | # Auto traits 2 | 3 | Auto traits permit automatically implementing a trait for types which contain 4 | fields implementing the trait. That is, they are fairly close to an automatic 5 | derive. They describe properties of types rather than behaviors; current stable 6 | Rust has several auto traits: `Send`, `Sync`, `Unpin`, `UnwindSafe`, 7 | `RefUnwindSafe`. 8 | 9 | `Freeze` is also an auto trait indirectly observable on stable; it is used by 10 | the compiler to determine which types can be placed in read-only memory, for 11 | example. 12 | 13 | Auto traits are tracked in [rust-lang/rust#13231], and are also sometimes 14 | referred to as OIBITs ("opt-in built-in traits"). 15 | 16 | As of November 2020, the language team feels that new auto traits are unlikely 17 | to be added or stabilized. See [discussion][freeze discussion] on the addition of `Freeze` for 18 | context. There is a fairly high burden to doing so on the ecosystem, as it 19 | becomes a concern of every library author whether to implement the trait or not. 20 | 21 | Each auto trait represents a semver compatibility hazard for Rust libraries, as 22 | adding private fields can remove the auto trait unintentionally from a type. 23 | 24 | Stabilizing the ability to define auto traits also allows "testing" for the 25 | absence of a specific type: 26 | 27 | ```ignore 28 | auto trait NoString {} 29 | impl !NoString for String {} 30 | ``` 31 | 32 | This is not something we generally want to allow, as it makes almost any change 33 | to types semver breaking. That means that stabilizing defining new auto traits is 34 | currently unlikely. 35 | 36 | [rust-lang/rust#13231]: https://github.com/rust-lang/rust/issues/13231 37 | [freeze discussion]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Freeze.20stabilization.20and.20auto-trait.20backcompat/near/214251682 38 | -------------------------------------------------------------------------------- /src/design_notes/autoref_ops.md: -------------------------------------------------------------------------------- 1 | # Autoref/Autoderef in operators 2 | 3 | Rust permits overriding most of the operators (e.g., `+`, `-`, `+=`). In part 4 | due to `Copy` types not auto-dereferencing, it is common to have `T + &T` 5 | or `&T + &T`, with potentially many levels of indirection on either side of the 6 | operator. 7 | 8 | There is desire in general to avoid needing to both add impls for referenced 9 | versions of types because they: 10 | 11 | - bloat documentation 12 | - are never quite sufficient (always more references are possible) 13 | - can cause inference regressions, as the compiler cannot in general know that 14 | `&T + &T` is essentially equivalent at runtime to `T + T`. 15 | 16 | The inference regressions are the primary target of historical discussions. 17 | 18 | The tradeoff to some feature like this may either mean that the exact impl 19 | executed at runtime is harder to determine, or that the compiler is 20 | synthetically generating new implementations for some subset of types, 21 | potentially adding confusion around which impls are actually present. 22 | 23 | However, generic code may want the impls on references because the generic code 24 | may not want to require `T: Copy`. One version of this could involve 25 | something like `default impl Add<&T> for &T` so that people don't *need* 26 | to write special impls themselves. It's worth noting that this still would need 27 | some special support in the compiler to avoid the two possible impls leading to 28 | inference regressions. 29 | 30 | ## History 31 | 32 | The standard library initially had just the basic impls of the operator traits 33 | (e.g., `impl Add for u64`) but has since gained `&u64 + &u64`, `u64 + &u64` 34 | and `&u64 + u64`. These impls usually cause some amount of inference breakage in 35 | practice. 36 | 37 | Especially with non-Copy types (for example bigints), forcing users to add references can be 38 | increasingly verbose: `&u * &(&(&u.square() + &(&a * &u)) + &one)`, for example. 39 | 40 | There have also been a number of discussions on RFCs and issues, including: 41 | - [Rust tracking issue #44762](https://github.com/rust-lang/rust/issues/44762) 42 | - This includes some implementation/mentoring notes. 43 | - [RFC 2147](https://github.com/rust-lang/rfcs/pull/2147) 44 | - [Trying to add T op= &T](https://github.com/rust-lang/rust/pull/41336) 45 | - Showcases dealing with inference breakage regressions when adding new 46 | reference-taking impls. 47 | -------------------------------------------------------------------------------- /src/design_notes/copy_ergonomics.md: -------------------------------------------------------------------------------- 1 | # Copy type ergonomics 2 | 3 | ## Background 4 | 5 | There are a number of pain points with `Copy` types that the lang team is 6 | interested in exploring, though active experimentation is not currently ongoing. 7 | 8 | Some key problems are: 9 | 10 | ## `Copy` cannot be implemented with non-`Copy` members 11 | 12 | There are standard library types where the lack of a `Copy` impl is an 13 | active pain point, e.g., [`MaybeUninit`](https://github.com/rust-lang/rust/issues/62835) 14 | and [`UnsafeCell`](https://github.com/rust-lang/rust/issues/25053), when the 15 | contained type is actually `Copy`. 16 | 17 | ### History 18 | 19 | * `unsafe impl Copy for T` which avoids the requirement that T is recursively 20 | Copy, but is obviously unsafe. 21 | * https://github.com/rust-lang/rust/issues/25053#issuecomment-218610508 22 | * `Copy` is dangerous on types like `UnsafeCell` where `&UnsafeCell` 23 | otherwise would not permit access to `T` in [safe 24 | code](https://github.com/rust-lang/rust/issues/25053#issuecomment-98447164). 25 | 26 | ## `Copy` types can be (unintentionally) copied 27 | 28 | Even if a type is Copy (e.g., `[u8; 1024]`) it may not be a good idea to make 29 | use of that in practice, since copying large amounts of data is slow. This is 30 | primarily a performance concern, so the problem is usually that these copies are 31 | easy to miss. However, depending on the size of the buffer, it can also be a 32 | correctness concern as it may cause an unintended stack overflow with too many 33 | accidental copies. 34 | 35 | Should we want to lint on this code, deciding on a size threshold may be 36 | difficult. It's not generally possible for the compiler to know whether a 37 | particular copy operation is likely to lead to stack overflow or undesirable 38 | performance. We don't have examples yet of cases where there's desirable large 39 | copies (that should not be linted against) or concrete cases where the copies 40 | are accidental; collecting this information would be worthwhile. 41 | 42 | Implementations of `Copy` on closures and arrays are the prime example of Rust 43 | currently being overeager with the defaults in some contexts. 44 | 45 | This also comes up with `Copy` impls on `Range`, which would generally be 46 | desirable but is error-prone given the `Iterator/IntoIterator` impls on ranges. 47 | 48 | The example here does not compile today (since Range is not Copy), but would be 49 | unintuitive if it did. 50 | 51 | ```rust,compile_fail 52 | let mut x = 0..10; 53 | let mut c = move || x.next(); 54 | println!("{:?}", x.next()); // prints 0 55 | println!("{:?}", c()); // prints 0, because the captured x is implicitly copied. 56 | ``` 57 | 58 | This example illustrates the range being copied into the closure, while the user 59 | may have expected the name "x" to refer to the same range in both cases. 60 | 61 | The move keyword here likely disambiguates this particular case for users, but 62 | in closures with more captures it may be not as obvious that the range type in 63 | particular was copied in. 64 | 65 | A lint has been [proposed](https://github.com/rust-lang/rust/issues/45683) to 66 | permit Copy impls on types where Copy is likely not desirable with particular 67 | conditions (e.g., Copy of IntoIterator-implementing types after iteration). 68 | 69 | Note that "large copies" comes up with moves as well (which are copies, just 70 | taking ownership as well), so a size-based lint is plausibly desirable for both. 71 | 72 | ### History 73 | 74 | * Proposed lint: [#45683](https://github.com/rust-lang/rust/issues/45683) 75 | 76 | ## References to `Copy` types 77 | 78 | Frequently when dealing with code generic over T you end up needing things like 79 | `[u8]::contains(&5)` which is ugly and annoying. Iterators of copy types also 80 | produce `&&u64` and similar constructs which can produce unexpected type errors. 81 | 82 | ```rust 83 | for x in &vec![1, 2, 3, 4, 5, 6, 7] { 84 | process(*x); // <-- annoying that we need `*x` 85 | } 86 | 87 | fn process(x: i32) { } 88 | ``` 89 | 90 | ```rust 91 | fn sum_even(v: &[u32]) -> u32 { 92 | // **v is annoying 93 | v.iter().filter(|v| **v % 2 == 0).sum() 94 | } 95 | ``` 96 | 97 | Note that this means that you in most cases want to "boil down" to the inner 98 | type when dealing with references, i.e., `&&u32` you actually want `u32`, not 99 | `&u32`. Notably, though, this may *not* be true if the Copy type is something 100 | more complex (e.g., a future Copy Cell), since then `&Cell` is quite different 101 | from a `Cell`, the latter being likely useless for modification at least. 102 | 103 | There is also plausibly performance left on the table with types like `&&u64`. 104 | 105 | Note that this interacts with the unintentional copies (especially of large 106 | structures). 107 | 108 | This could plausibly be done with moved values as well, so long as the 109 | semantics match the syntax (e.g. `wants_ref(foo)` acts like `wants_ref(&{foo})`) 110 | similar to how one can pass `&mut` to something that only wants `&`. 111 | This would be a tradeoff: in some cases people may want the type-checker to flag such cases and require explicitly taking a reference, while in other cases people may want the compiler to automatically make such code work. We would want to consider and evaluate this tradeoff, and whether we can usefully separate such cases. 112 | 113 | ### History 114 | 115 | * [RFC 2111 (not merged)](https://github.com/rust-lang/rfcs/pull/2111) 116 | * [Rust tracking issue (closed)](https://github.com/rust-lang/rust/issues/44763) 117 | * "Allow owned values where references are expected" in [rust-roadmap-2017#17](https://github.com/rust-lang/rust-roadmap-2017/issues/17) 118 | -------------------------------------------------------------------------------- /src/design_notes/eager_drop.md: -------------------------------------------------------------------------------- 1 | # Eager drop design note 2 | 3 | - Project proposal [rust-lang/lang-team#86](https://github.com/rust-lang/lang-team/issues/86) 4 | 5 | ## Observations 6 | 7 | ### Any attempt to make drop run more eagerly will have to take borrows into account 8 | 9 | The original proposal was to use "CFG dead" as a criteria, but it's pretty clear that this will not work well. Example: 10 | 11 | ```rust= 12 | { 13 | let x = String::new(); 14 | let y = &x; 15 | // last use of x is here 16 | println!("{}", y); 17 | // but we use y here 18 | ... 19 | } 20 | ``` 21 | 22 | Here, the fact that `y` (indirectly) uses `x` feels like an important thing to take into account. 23 | 24 | ### Some destructors can be run "at any time"... 25 | 26 | Some destructors have very significant side-effects. The most notable example is dropping a lock guard. 27 | 28 | Others correspond solely to "releasing resources": freeing memory is the most common example, but another might be replacing an entry in a table because you are done using it. 29 | 30 | ### ...but sometimes that significance is only known at the call site 31 | 32 | However, it can be hard to know what is significant. For a lock guard, for example, if the lock is just being used to guard the data, then moving the lock release early is actually _desirable_, because you want to release the lock as soon as you are doing changing the data. But sometimes you have a `Mutex<()>`, in which case the lock has extra semantics. It's hard to know for sure. 33 | 34 | ### Smarter drop placement will mean that adding uses of a variable changes when its destructor runs 35 | 36 | This is not necesarily a problem, but it's an obvious implication: right now, the drop always runs when we exit the scope, so adding further uses to a variable has no effect, but that would have to change. That could be surprising (e.g., adding a debug printout changes the time when a lock is released). 37 | 38 | In contrast, if you add an early drop `drop(foo)` today, you get helpful error messages when you try to use it again. 39 | 40 | In other words, it's useful to have the _destructor_ occurring at a known time (sometimes...). 41 | 42 | ### Today's drop rules are, however, a source of confusion 43 | 44 | The semantics of `let _ = ` have been known to caught a lot of confusion, particularly given the interaction of place expressions and value expresssions: 45 | 46 | - `let _ = foo` -- no effect 47 | - `let _ = foo()` -- immediately drops the result of invoking `foo()` 48 | - `let _guard = foo` -- moves `foo` into `_guard` and drops at the end of the block 49 | - `let _guard = foo()` -- moves `foo()` into `_guard` and drops at the end of the block 50 | 51 | Another common source of confusion is the lifetimes of temporaries in `match` statements and the like: 52 | 53 | ```rust 54 | match foo.lock().data.copy_out() { 55 | ... 56 | } // lock released here! 57 | ``` 58 | 59 | `let guard = foo; ...; drop(guard);` has the advantage of explicitness, so does something like `foo.with(|guard| ...)` 60 | 61 | ### Clarity for unsafe code can be quite important 62 | 63 | There are known footguns today with the timing of destructors and unsafe code. For example, `CString::new().as_ptr()` is a common thing people try to do that does not work. Eager destructors would enable more motion, which might exacerbate the problem. 64 | 65 | In addition, unsafe code means we might not be able to know the semantics associated with a destructor, such as what precisely a `Mutex<()>` guards, and moving a drop earlier *will* break some unsafe code in hard-to-detect ways. 66 | 67 | ## Alternatives 68 | 69 | - Scoped methods 70 | - let blocks 71 | - "Defer" type constructs or scoped guard type constructs from other languages 72 | - Go 73 | - D 74 | - Python 75 | - Built-in macros or RAII/closure-based helpers in the standard library. 76 | - Note that the [scopeguard](https://crates.io/crates/scopeguard) crate offers macros like `defer!` that inject a let into the block. 77 | -------------------------------------------------------------------------------- /src/design_notes/int_literal_as_float.md: -------------------------------------------------------------------------------- 1 | # Can we allow integer literals like `1` to be inferred to floating point type? 2 | 3 | ## Background 4 | 5 | In rust today, an integer like `1` cannot be inferred to floating 6 | point type. This means that valid-looking numeric expressions like 7 | `22.5 + 1` will not compile, and one must instead write `22.5 + 8 | 1.0`. Can/should we change this? 9 | 10 | ## History 11 | 12 | This was discussed on Zulip in [May 2020]. Some of the key highlights from the discussion were: 13 | 14 | * Floating point literals are prone to many surprises that integers 15 | are not. For [example][], `20_000_000 + 1`, if inferred to `f32` 16 | type, would have the final value `20_000_000.0`. This leads some to 17 | conclude that ["the surprise factor of floats is so high that they 18 | are qualitatively different than integers"][surprise]. 19 | * But there are a lot of similar surprising things: 20 | * [`20_000_001_f32`, for example, is also going to be `20_000_000`.](https://zulip-archive.rust-lang.org/213817tlang/43153EditionRequestlet1beafloatliteral.html#196930252) 21 | * Integer overflow can mean that `255 + 1` has the value 0. 22 | * Some key questions to consider: 23 | * [How often does adding `.0` result in some insight?](https://zulip-archive.rust-lang.org/213817tlang/43153EditionRequestlet1beafloatliteral.html#196926142) 24 | * How much would *seeing* the `.0` help to debug a tricky problem? 25 | * Balanced against the annoyance and surprise factor. 26 | 27 | [example]: https://zulip-archive.rust-lang.org/213817tlang/43153EditionRequestlet1beafloatliteral.html#196887384 28 | [surprise]: https://zulip-archive.rust-lang.org/213817tlang/43153EditionRequestlet1beafloatliteral.html#196887384 29 | 30 | [May 2020]: https://zulip-archive.rust-lang.org/213817tlang/43153EditionRequestlet1beafloatliteral.html 31 | -------------------------------------------------------------------------------- /src/how_to.md: -------------------------------------------------------------------------------- 1 | # Lang team "how to" guide 2 | 3 | This section includes instructions on how to do various interactions with the lang team. 4 | -------------------------------------------------------------------------------- /src/how_to/design_meeting.md: -------------------------------------------------------------------------------- 1 | # Proposing a topic for a design meeting 2 | 3 | You can propose a topic for a design meeting by opening an [Design 4 | meeting proposal] issue on the lang-team repository. We schedule meetings in our monthly 5 | planning meeting. 6 | 7 | [design meeting proposal]: https://github.com/rust-lang/lang-team/issues/new/choose 8 | 9 | Every design meeting begins by reading a document and leaving comments. That document 10 | must be prepared 24 hours in advance of the design meeting and posted on the issue. 11 | If you propose an issue, you should be willing to prepare that document, or else indicate 12 | who will do the preparation. 13 | 14 | Typically, design meetings are associated with active initiatives: you may wish to 15 | [propose an initiative](./propose.md) instead. 16 | -------------------------------------------------------------------------------- /src/how_to/new_lint.md: -------------------------------------------------------------------------------- 1 | # How do I propose a new lint, or extend an existing one? 2 | 3 | For small lints, you can follow the [policy for smaller changes](./propose.md): implement the lint, open a PR, and then [nominate](./nominate.md) it for lang-team attention. 4 | 5 | We may request an RFC if: 6 | 7 | * the lint is on (warn or higher level) by default, and is expected to affect a lot of users 8 | * the lint is controversial 9 | * the lint sets a (new) direction for Rust -- for example, changing an existing pattern to a different one, even if the pattern isn't widely used 10 | * e.g., deprecating a syntax to make room for a possible new language feature 11 | 12 | If in doubt, you can always raise the idea on Zulip first. -------------------------------------------------------------------------------- /src/how_to/nominate.md: -------------------------------------------------------------------------------- 1 | # Nominate an issue 2 | 3 | You can raise issues to lang team attention by tagging them with `I-lang-nominated`. We scan through nominated issues during our [triage meetings](../meetings/triage.md). For each issue, we try to answer questions and reach decisions on the question being discussed in the issue. 4 | 5 | ## How to nominate 6 | 7 | Add a **self-sufficient** comment to the issue that explains why you are nominated the issue and includes the text `@rustbot label +I-lang-nominated`. For example: 8 | 9 | ``` 10 | @rustbot label +I-lang-nominated 11 | 12 | I am nominating this for lang-team attention. We have been discussing the pros/cons of updating the type-checking rules for foo bar. The options on the table are as follows: 13 | 14 | * Allow type mismatches: This is good because blah. 15 | * Disallow type mismatches: This is good because blah. 16 | 17 | Where should we go from here? 18 | ``` 19 | 20 | The ideal comment will identify precisely what question you would like answered. Please try to make the comment easy for us to parse and understand without requiring a lot of context. We encourage links to internals or Zulip so we can dive into the details, but it really helps us give useful answers if you can summarize the key details up front. 21 | 22 | If you're not a member of the Rust team on GitHub you'll get an error from rustbot when trying to add the label - please make the comment (following the guidelines above) anyway, and ping the lang team on our (chat platform)[../chat_platform.md) asking for the label to be added. 23 | 24 | If your comment requires more than 5-10 minutes of reading and discussion to understand and effectively respond to, consider [filing a meeting proposal](./design_meeting.md) instead. This will give you ~60 minutes to present your question and the lang team more time to analyze it. We may punt the question back to you with an ask to do so if the question isn't answerable in our triage meeting time. 25 | 26 | ## How quickly will the lang team answer? 27 | 28 | We try to be prompt, but sometimes we are not. Othertimes, we discuss the issue, but fail to leave the follow-up comment, because we're only human. Please feel free to raise the topic on Zulip or reach out to a lang team member. 29 | 30 | ## Repositories where we look for nominations 31 | 32 | Nomination is currently supported on the following repositories: 33 | 34 | - rust-lang/rfcs 35 | - rust-lang/rust 36 | - rust-lang/reference 37 | - rust-lang/lang-team 38 | 39 | (This set is defined by the `nominated` list in the [triagebot source code](https://github.com/rust-lang/triagebot/blob/master/src/agenda.rs)) 40 | 41 | 42 | 43 | [rustbot]: https://github.com/rust-lang/triagebot/wiki 44 | -------------------------------------------------------------------------------- /src/how_to/stabilize.md: -------------------------------------------------------------------------------- 1 | # Stabilize a feature 2 | 3 | The final step in the [language-change process](./propose.md) is to **stabilize** a feature. Stabilization works as follows: 4 | 5 | * Author a [stabilization report][sg]: 6 | * Briefly recap the feature's design from the RFC -- you don't have to go into detail, we can re-read the RFC. 7 | * Give detailed descriptions of how the feature's design has changed since the RFC was approved! 8 | * Summarize any major decisions that were made during the implementation process. 9 | * Verify that the feature is fully implemented. Look for tests covering all the major pieces of the RFC and include them in the stabilization report. 10 | * Provide answers to any "unresolved questions" listed in the RFC. 11 | * Describe the implementation history of the feature (optional). 12 | * Prior to stabilizing, we need to coordinate with other teams: 13 | * An open PR editing the reference to describe the change is required. (You don't personally have to author it, but there needs to be an open PR, and ideally one that has been edited and is approved modulo actual stabilization by one of the repo maintainers.) 14 | * If the feature affects the type system, you should nominate for @rust-lang/types to check for their approval. 15 | * If the feature adds new syntax, you should should nominate for the style team to get their approval. 16 | * The lang team will read the report and eventually move to FCP. Per our [decision process](../decision_process.md), full consensus is required, as this is an irreversible change. 17 | 18 | See also the rustc-dev-guide's [stabilization guide][sg]. 19 | 20 | [sg]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html -------------------------------------------------------------------------------- /src/initiatives.md: -------------------------------------------------------------------------------- 1 | # Initiatives 2 | 3 | A lang team **initiative** is some active effort with a clear goal or deliverable. 4 | Typically initiatives are changes to the language, but they could also be documentation, specifications, or something internal to the lang team. 5 | 6 | ## [Active initiatives][pb] 7 | 8 | Active initiatives are initiatives that have been assigned a lang-team [Liaison] and which are actively underway. A complete list can be found in [this GitHub project board][pb]. Note that this list doesn't represent all unstable features; older features in particular were added without active initiatives. 9 | 10 | Each initiative on the project board is linked to a tracking issue and has a status: 11 | 12 | * The [Owner] and [Liaison] are assigned to the issue. 13 | * If the initiative has a dedicated repository, the issue is created on that repository (some initiatives don't require their own repos; they are found on rust-lang/rust or rust-lang/lang-team). 14 | * The [Stage] of the initiative: 15 | * [Experimental] -- Drafting RFC; implementation work may begin on nightly as well 16 | * [Development] -- Approved RFC; implementation is in progress on nightly 17 | * [Feature complete][fc] -- Implementation is complete on nightly and ready for widespread testing 18 | * [Stabilized] -- Implementation is complete and available on stable 19 | * To be stabilized, there must be a pending PR adding the feature to the Rust reference, but this PR may not yet have landed. 20 | * Other forms of integration, such as rustfmt, often take place after stabilization as well. 21 | 22 | ## Proposed initiatives 23 | 24 | You can see the [currently proposed initiatives] on Github. We review this list during [triage meetings](./meetings.md) and decide whether to assign a liaison or close the proposal. If initiatives haven't received a liaison after 6 weeks of activity, we take that as a sign that there is no enthusiasm to pursue this and close the issue, but you are welcome to re-open the issue if you believe someone would be willing to liaison. 25 | 26 | [currently proposed initiatives]: https://github.com/rust-lang/lang-team/issues?q=is%3Aissue+is%3Aopen+label%3Amajor-change 27 | 28 | ## How does one propose a new initiative? 29 | 30 | It's easy! You just open a short issue describing your idea. Read more in the [process](./initiatives/process.md) page! 31 | 32 | [pb]: https://github.com/orgs/rust-lang/projects/16/ 33 | [proposal]: ./initiatives/process/stages/proposal.md 34 | [Experimental]: ./initiatives/process/stages/experimental.md 35 | [Development]: ./initiatives/process/stages/development.md 36 | [fc]: ./initiatives/process/stages/feature_complete.md 37 | [Stabilized]: ./initiatives/process/stages/stabilized.md 38 | [Stage]: ./initiatives/process/stages.md 39 | [Owner]: ./initiatives/process/roles/owner.md 40 | [Liaison]: ./initiatives/process/roles/owner.md 41 | -------------------------------------------------------------------------------- /src/language-change-policy.md: -------------------------------------------------------------------------------- 1 | # Proposing a change to the language 2 | -------------------------------------------------------------------------------- /src/leads.md: -------------------------------------------------------------------------------- 1 | # Lang team leadership 2 | 3 | Lang team leads drive the overall team agenda and tend to its well-being. They generally chair the meetings, keep an eye out for conflicts, and are to some extent the decision makers of last resort. They drive the roadmap process. They also post blog posts updating the public (possibly through delegation). 4 | 5 | ## Process to select leads 6 | 7 | We do not have a fixed point in time for selecting new leadership. However, when we opt to select new leadership, the process is as follows: 8 | 9 | * Current lang team leads send out an email or message seeking nominations 10 | * Lang team members (including the current leads) suggest candidates for new leads 11 | * Members may nominate themselves. 12 | * Leads may nominate to continue leading. 13 | * Based on these nominations, leads propose the next set of leads and team members ratify the choice 14 | * A private meeting (lang team members only) may be useful to discuss. 15 | * It is generally recommended to pair one new co-lead with an older one who can advise. 16 | * To avoid burnout, rotation of leadership is recommended. 17 | 18 | ## Qualifications 19 | 20 | Questions to ask when nominating or selecting a lead: 21 | 22 | * Does this person have time to be a lang team lead? 23 | * Are they widely respected amongst the team? 24 | * Do they excel at resolving disputes, even amongst lang team members? 25 | * All leads are lang team members, so they are are assumed to meet the general criteria for lang team membership, but typically leads excel at the question of leading others to productive discussion. 26 | -------------------------------------------------------------------------------- /src/meetings.md: -------------------------------------------------------------------------------- 1 | # Meetings 2 | 3 | The lang team has several kinds of standing meetings. 4 | 5 | * [Triage meetings](./meetings/triage.md) 6 | * [Design and planning meetings](./meetings/design.md) 7 | * [Backlog bonanza](./meetings/backlog-bonanza.md) 8 | 9 | Unless otherwise noted, all of our meetings are open to the public for anyone to attend. You will find the timing and event details on our [lang team calendar](./calendar.html). We publish notes and minutes in written form in this github repository. 10 | 11 | ## Recording policy 12 | 13 | Dy default, our triage and design meetings are **not recorded**, in order to encourage engagement from a broad audience. We may record certain design meetings, evaluated on a case-by-case basis, and only with the agreement of all participants. Any intention to record a design meeting will be established at that time that meeting is scheduled during the monthly planning meeting and included in the blog post announcing the upcoming meetings. 14 | 15 | Our [YouTube playlist] has recordings of some of our past meetings (along with automatically created subtitles). 16 | 17 | [youtube playlist]: https://www.youtube.com/playlist?list=PL85XCvVPmGQg-gYy7R6a_Y91oQLdsbSpa 18 | -------------------------------------------------------------------------------- /src/meetings/backlog-bonanza.md: -------------------------------------------------------------------------------- 1 | # Backlog bonanza 2 | 3 | Backlog bonanza is a particular kind of design meeting. We often schedule a backlog bonanza for those weeks where we don't have more specific things to discuss. The idea is to go through each tracking issue and "disposition them". The goal is to identify what we ought to do with this particular unstable feature; e.g., what is blocking this from being stabilized? Do we still want this? Is it perma-unstable? 4 | 5 | ## When does backlog bonanza take place? 6 | 7 | Backlog bonanza meetings are typically scheduled as [design meetings](design.md). 8 | 9 | ## Can I attend? 10 | 11 | Yes! Design meetings are open to the public. You'll find the details on our [calendar](../calendar.md). 12 | 13 | ## What labels do we apply to issues? 14 | 15 | Here are the labels we apply during the process and their meaning: 16 | 17 | * S-tracking-ready-to-stabilize: Needs a stabilization PR (good to go :train:) 18 | * S-tracking-needs-to-bake: Needs time to bake (set a date? other criteria?) 19 | * S-tracking-impl-incomplete: Not code complete or blocking bugs 20 | * S-tracking-unimplemented: Implementation not begun 21 | * S-tracking-design-concerns: Blocking design concerns 22 | * This might be "doesn't quite seem to deliver value we hoped for" or "something doesn't feel right" 23 | * S-tracking-perma-unstable 24 | * Internal implementation detail of rustc, stdlib 25 | * S-tracking-needs-investigation 26 | 27 | ## Where can I find the minutes? 28 | 29 | Currently the minutes are tracked in the issues themselves, but we also create hackmd documents in the [Rust lang team](https://hackmd.io/team/rust-lang-team?nav=overview). 30 | -------------------------------------------------------------------------------- /src/meetings/design.md: -------------------------------------------------------------------------------- 1 | # Design meetings 2 | 3 | We reserve a weekly slot for our planning and design meetings. 4 | A **design meeting** is a one-hour deep-dive discussion into some particular 5 | topic. Each meeting is centered around a document that is prepared for 6 | that meeting explaining the details of what is to be discussed; we begin by reading 7 | the document and then discussing its contents. These meetings are used for all kinds 8 | of purposes, such as brainstorming, getting feedback on an idea, or building 9 | consensus around a specific proposals. 10 | 11 | ## How are design meetings scheduled? 12 | 13 | To schedule design meetings, we hold a special **planning meeting** once per month. 14 | In that meeting, we choose what design meetings we will hold the rest of the month. 15 | 16 | To generate the agenda for the planning meeting, you can use the following link and then copy/paste the generated text into a fresh hackmd page: 17 | 18 | https://triage.rust-lang.org/agenda/lang/planning 19 | 20 | ## How do I propose a design meeting? 21 | 22 | You need to open an issue, [as described here](../how_to/design_meeting.md). 23 | 24 | ## Can I attend? 25 | 26 | Yes! Design meetings are open to the public. You'll find the details on our [calendar](../calendar.md) and a list of the upcoming meetings in the [design meeting schedule][ghp]. 27 | 28 | ## How does a design meeting work? 29 | 30 | Before the meeting starts, someone has to prepare a document -- we recommend using hackmd and using [this template](https://hackmd.io/VJrbVMeqT4uUDBRVncHyTw). 31 | 32 | When the meeting starts, send out the link to your document on Zulip (and on Zoom, if you like). Everyone will start to read it. **There is no expectation that people will read the document in advance.** 33 | 34 | As they read, people will append questions to the end of the document -- the template has a space for this. We recommend making each question into a markdown section (e.g., `### Why is this document so great?`). People will append their question in that section. 35 | 36 | After everyone is done reading, whoever is driving the meeting will pick questions to discuss. Typically we go in linear order but that's not required, we can go in whatever order seems best. 37 | 38 | ## Where can I find the minutes? 39 | 40 | The [design-meeting-minutes directory][dnm] contains the document from each meeting along with any questions that were asked and the ensuing disceussion. 41 | 42 | [dnm]: https://github.com/rust-lang/lang-team/tree/master/design-meeting-minutes 43 | [ghp]: https://github.com/orgs/rust-lang/projects/31/views/10 44 | -------------------------------------------------------------------------------- /src/meetings/triage.md: -------------------------------------------------------------------------------- 1 | # Triage meeting 2 | 3 | The weekly triage meeting is when we go over the newly filed project 4 | proposals along with issues that have been nominated for lang-team 5 | feedback. We also get regular updates from the active project groups 6 | so we can stay on top of what is going on. 7 | 8 | ## Can I attend? 9 | 10 | Yes! The triage meeting is open to the public. You'll find the details 11 | on our [calendar](src/../../calendar.md). 12 | 13 | ## How do I get something on the agenda? 14 | 15 | The easiest way to get something on the agenda is to [nominate it](../how_to/nominate.md). The agenda is automatically built by triagebot from [this template](https://github.com/rust-lang/triagebot/blob/master/templates/lang_agenda.tt). We review pending [initiative proposals](../how_to/propose.md), [nominated](../how_to/nominate.md) issues and PRs from a variety of repositories, as well as pending RFC requests. 16 | 17 | [triagebot]: https://github.com/rust-lang/triagebot 18 | 19 | ## Can I generate the agenda myself? 20 | 21 | Sure. You can visit the following link and one will be generated for you for (the current date): 22 | 23 | https://triage.rust-lang.org/agenda/lang/triage 24 | 25 | Alternatively, clone the [triagebot] repo and run this 26 | 27 | ```bash 28 | > cargo run --bin lang agenda 29 | ``` 30 | 31 | If you install the `hackmd-cli`, you can do this: 32 | 33 | ```bash 34 | cargo run --bin lang agenda | hackmd-cli import 35 | ``` 36 | 37 | ## Where can I find the minutes? 38 | 39 | [Triage meeting minutes are available in this directory.][tmm] 40 | 41 | [tmm]: https://github.com/rust-lang/lang-team/tree/master/minutes 42 | -------------------------------------------------------------------------------- /src/membership.md: -------------------------------------------------------------------------------- 1 | # Becoming and being a lang-team member 2 | 3 | Lang team members are the ones who ultimately decide the syntax/semantics of the Rust language. They judge whether a given piece of Rust syntax ought to compile and, if it does, what should happen when it runs. 4 | 5 | ## Relations to other teams 6 | 7 | Lang team members should be familiar with how the compiler works, but they don't need to drive its implementation or even work on it. Compiler implementation details are the job of the [compiler team]. Note that compiler team members are encouraged to raise concerns if they feel that the desired design cannot be implemented in a reasonable and maintainable way. 8 | 9 | [compiler team]: https://rust-lang.github.io/compiler-team/ 10 | 11 | Lang team members have to know the language inside and out, but they don't necessarily need deep type theory background. Working out the formal semantics of the language as well as diving into very detailed questions is covered by the [types team]. Types team members are encouraged to raise concerns if they feel that the desired design cannot be made sound or is internally inconsistent. 12 | 13 | [types team]: https://rust-lang.github.io/types-team/ 14 | 15 | ## Expectations 16 | 17 | Lang team members are expected to 18 | 19 | * Help to advance the state of the language by some combination of participating in discussions on RFCs and Zulip, authoring and editing RFCs, and shepherding features through the stabilization process. 20 | * Attend triage and design meetings regularly. 21 | * Promptly respond to RFC decisions by reviewing the question and either checking box or raising concerns 22 | 23 | ## Process to add a new member 24 | 25 | Lang team members can propose new additions to the team as follows: 26 | 27 | * Lang team member prepares a short write-up to propose candidate to the rest of the team 28 | * The write-up should draw on the qualifications below, giving examples where the candidate demonstrated the various criteria 29 | * Leads check with moderation team for known flags, surface to team if any. 30 | * The decision to add must have unanimous consent, similar to any other decision. Objections may be raised in a private team discussion, or by contacting a team lead. 31 | 32 | **Important:** Discussions about potential new members are kept strictly confidential. Email or voice conversation are often preferred because they doesn't keep publicly available records. 33 | 34 | ### Qualifications 35 | 36 | These are the questions we ask ourselves when deciding whether someone would be a good choice as a lang team member. 37 | 38 | * Has this person demonstrated **strong language design skills**? 39 | * Have they made notable contributions to an area of the language, such as leading an impactful initiative to completion? 40 | * Are they able to identify flaws in a design and, just as importantly, come up with creative solutions? 41 | * Is this person **responsible**? 42 | * When they agree to take on a task, do they either get it done or identify that they are not able to follow through and ask for help? 43 | * Is this person able to **lead others to a productive conversation**? 44 | * Are there times when a conversation was stalled out and this person was able to step in and get the design discussion back on track? 45 | * This could have been by suggesting a compromise, but it may also be by asking the right questions or encouraging the right tone. 46 | * Is this person able to **disagree collaboratively, constructively, and with empathy**? 47 | * The expectation is that team members go "above and beyond" the [Rust code of conduct](https://www.rust-lang.org/policies/code-of-conduct), embodying not only the letter but also the spirit. 48 | * Do they help turn disagreements into collaborations, jointly seeking a mutually satisfying solution based on everyone's values? 49 | * When they are having a debate, do they make an active effort to understand and repeat back others' points of view? 50 | * If they *or others* have a concern, do they engage actively to make sure it is understood and to look for ways to resolve it? 51 | * Do they respect others when disagreeing, seek earnestly to understand others' points of view, and show that they value others for bringing forward reasonable disagreement and dissent? 52 | * Is this person **active**? 53 | * Are they attending the [triage meeting](./meetings/triage.md) and [design meetings](./meetings/triage.md) regularly? (Meetings are open for anyone to attend, but note that merely attending meetings is not enough to become a team member!) 54 | * Either in meeting or elsewhere, do they comment on disussions and otherwise? 55 | * Does this person have an **overall desire to improve the language**, rather than a strong interest in some particular domain? 56 | * Everyone have preferences, but members are responsible for balancing a wide array of interests. Someone with very specialized interest may be a better choice for a lang team advisor. 57 | 58 | Keep in mind that qualifications are not a checklist and membership decisions are ultimately made on a case-by-case basis. **If you are interested in joining the lang team, we recommend you reach out to the lead(s) to talk about the path forward.** 59 | -------------------------------------------------------------------------------- /src/roadmaps.md: -------------------------------------------------------------------------------- 1 | This section contains lang-team roadmaps. 2 | -------------------------------------------------------------------------------- /src/welcome.md: -------------------------------------------------------------------------------- 1 | # Welcome 2 | 3 | Welcome to the repository for the Rust Language Design Team. This 4 | page stores our administrative information, meeting minutes, as well 5 | as some amount of design constraints. It's always a 6 | work-in-progress (insert omnipresent mid 90s logo for under 7 | construction here). 8 | 9 | ## What is the lang team 10 | 11 | The lang team generally governs the "surface area" of the language, meaning both what code compiles and what happens when it executes. For new language features, we also assume a general "project management" role, in that we track the feature as it progresses from an idea, to implementation, and finally to stabilization. 12 | 13 | Note that implementation itself is governed by the [compiler team](https://github.com/rust-lang/compiler-team). To be very concrete, the lang team controls the spec, and the compiler team approves the implemenation and ensures that it meets the spec. Naturally, though, development is a collaborative process, and it often happens that the spec is altered in response to concerns that arise during implementation. 14 | 15 | We also work closely with the [types team](https://github.com/rust-lang/types-team), which owns the details of the type system design in much the same way as the compiler team owns the details of the implementation. 16 | 17 | Finally, there are often "grey areas" between the language and library teams, such as the addition of a new standard library trait that reflects a core system capability (e.g., `Future`). In those cases, the lang team is generally reponsible for deciding if we want the core capability, the libs team owns the API details. 18 | 19 | ## Key links 20 | 21 | * [Active initiatives project board](https://github.com/orgs/rust-lang/projects/16/) 22 | * Shows you the things that are currently under development (or exploration) within Rust. 23 | * You can [read more about initiatives here](./initiatives.md). 24 | * [Meeting calendar](./calendar.md), [triage meeting minutes](https://github.com/rust-lang/lang-team/tree/master/minutes), [design meeting minutes](https://github.com/rust-lang/lang-team/tree/master/design-meeting-minutes) 25 | * You can [read more about our meetings here.](./meetings.md). 26 | -------------------------------------------------------------------------------- /triagebot.toml: -------------------------------------------------------------------------------- 1 | [major-change] 2 | second_label = "final-comment-period" 3 | meeting_label = "to-announce" 4 | # can be found by looking for the first number in URLs, e.g. https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler 5 | zulip_stream = 243200 6 | zulip_ping = "T-lang" 7 | -------------------------------------------------------------------------------- /working-groups/README.md: -------------------------------------------------------------------------------- 1 | # Working Groups 2 | 3 | This directory contains the notes for each of the active working 4 | groups. Each folder contains a few files, along with files specific to 5 | that working group: 6 | 7 | - `README.md` -- describes the basic details of the working group and how to get involved 8 | - `NOTES.md` -- updated regularly with the latest news 9 | - `FAQ.md` -- a place to document the answer to frequently asked questions 10 | 11 | ## What is a working group? 12 | 13 | The lang team establishes a **working group** when we have a promising 14 | idea that we would like to pursue. This idea might be a new language 15 | feature, but it could also be other things, such as an effort to write 16 | a specification for some part of Rust. 17 | 18 | ## How can I get involved? 19 | 20 | If you see some working group that looks like it is doing something 21 | you would like to be involved in, take a look at its README.md 22 | file. It should give more context about what the working group is 23 | trying to do, where it is in the design process, and how you can 24 | contribute or follow along. 25 | 26 | 27 | -------------------------------------------------------------------------------- /working-groups/grammar/NOTES.md: -------------------------------------------------------------------------------- 1 | This file will contain summaries from the meetings where the Grammar WG 2 | synchronizes with the lang team and broader community. That hasn't happened 3 | yet. =) 4 | -------------------------------------------------------------------------------- /working-groups/grammar/README.md: -------------------------------------------------------------------------------- 1 | # Grammar Working Group 2 | ![working group status: active][status] 3 | 4 | The goal of the working group is to satisfy [RFC 1331] and produce a testable, 5 | canonical grammar for the Rust language. The primary audiences for the grammar 6 | are: 7 | 8 | - Rust RFC authors who wish to propose and communicate changes. 9 | - rustc and Rust tool developers who need an authoritative definition of the 10 | grammar. 11 | - To assist documentation efforts to communicate valid Rust syntax to users, 12 | and to facilitate the [Rust language specification]. 13 | 14 | - **Leads:** [@centril][centril], [@qmx][qmx] 15 | - **Meeting Notes:** [All][meeting-notes] 16 | - **Dedicated repository:** [rust-lang-nursery/wg-grammar][wg-grammar] 17 | 18 | [status]: https://img.shields.io/badge/status-active-brightgreen.svg?style=for-the-badge 19 | [centril]: https://github.com/centril 20 | [qmx]: https://github.com/qmx 21 | [wg-grammar]: https://github.com/rust-lang-nursery/wg-grammar 22 | [meeting-notes]: https://github.com/rust-lang-nursery/wg-grammar/blob/master/misc/meeting-notes.md 23 | 24 | # How can I get involved? 25 | 26 | If you'd like to get involved, the best idea right now is to introduce yourself 27 | in our discord channel -- and perhaps consider attending on our meetings. 28 | 29 | - **Discord channel:** [#wg-grammar][discord] 30 | 31 | ## Do I need to attend any meetings? 32 | 33 | We have a bi-weekly sync meeting. Check the [lang team meeting 34 | calendar][calendar] for the most up to date time. Attendance is not mandatory 35 | but recommended as this can be a good opportunity to ask questions and find new 36 | issues to work on. 37 | 38 | [calendar]:https://github.com/rust-lang/lang-team#meeting-calendar 39 | [discord]: https://discord.gg/dj9NjJR 40 | [RFC 1331]: https://github.com/rust-lang/rfcs/blob/master/text/1331-grammar-is-canonical.md 41 | [Rust language specification]: https://github.com/rust-lang-nursery/reference/ 42 | -------------------------------------------------------------------------------- /working-groups/meta/README.md: -------------------------------------------------------------------------------- 1 | # Meta Working Group 2 | ![working group status: active][status] 3 | 4 | The goal of the Meta Working Group is to figure out how the lang team 5 | working groups should work. You can read more about the purpose of the 6 | working group and how we plan to work in the [announcement on internals][announcement]. 7 | 8 | - **Leads:** [@nikomatsakis][nikomatsakis] 9 | - **Meeting Notes:** see the [minutes](minutes) directory; they are also posted to [this internals thread][internals] 10 | - **Discussion channel:** We hang out in [the `#t-lang/wg-meta` stream on Zulip][zulip] 11 | 12 | [announcement]: https://internals.rust-lang.org/t/announcing-lang-team-meta-working-group/9900 13 | [status]: https://img.shields.io/badge/status-active-brightgreen.svg?style=for-the-badge 14 | [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/196563-t-lang.2Fwg-meta 15 | [internals]: https://internals.rust-lang.org/t/lang-team-meta-working-group/9989 16 | 17 | # How can I get involved? 18 | 19 | Attend our meetings! You can find them on the [lang team 20 | calendar][calendar]. Alternatively, read [the minutes](minutes). You can add any 21 | responses into [the internals thread][internals]. Finally, hop onto 22 | [`#t-lang/wg-meta` on the Rust zulip][zulip] and say hi! 23 | 24 | [calendar]: https://github.com/rust-lang/lang-team/#meeting-calendar 25 | 26 | -------------------------------------------------------------------------------- /working-groups/meta/minutes/2019.05.09.md: -------------------------------------------------------------------------------- 1 | # Meta WG 2019.05.09 2 | 3 | [Video](https://www.youtube.com/watch?v=5iiWsbOeYbI) 4 | 5 | ## Agenda 6 | 7 | - “Roadmap” — 8 | - what documents / things do we expect to produce and in what order? 9 | - Look at upcoming (or previous) efforts and think about how they should function 10 | - try blocks — controversial / syntax 11 | - specialization — complicated 12 | - const generics 13 | - grammar — specification 14 | - unsafe-code-guidelines — partly specification, but with a different flavor 15 | - Links 16 | - [+A new RFC discussion model](https://paper.dropbox.com/doc/A-new-RFC-discussion-model-Nihr4wCQXeklWo6wWrFY2) may be interesting to read 17 | 18 | 19 | ## Process 20 | 21 | - we decide to start a WG 22 | - initially it is an exploratory phase; 23 | - looking at the problem, enumerating key examples 24 | - sketching out possible ways to address (and their effect on the examples) 25 | - “positive” 26 | - transition to “active phase” 27 | - agree upon: “general shape” of solution 28 | - “key examples” to fixed 29 | - also explain why the problem is worth fixing 30 | - Agreeing on problems is important 31 | - but there is a need to be iterative when uncovering the problems 32 | - sometimes you have rfcs that are motivated by “making syntax more uniform” or “removing special cases” 33 | - motivation is not unlocking something for users 34 | - still, the more specific effects we can cite, the better 35 | - the special cases that are to be fixed could in a sense by the “key examples” 36 | - want to avoid the “unstoppable train” effect that can happen 37 | - but js has some specific aspects, e.g. babel toolchain 38 | - really trying to go into user research, e.g. ergonomic changes 39 | - Niko: I’d like to see us working harder on the docs 40 | - would like to see the roles declared 41 | - can the same person play many roles 42 | - for smaller things, seems fine 43 | - for larger things like async-await, could be a problem 44 | - how much overhead to add? 45 | - will slow things down? 46 | - new/old things 47 | - what are roles 48 | - lang team representative 49 | - implementor(s) in the compiler 50 | - mentor/reviewer for the implementation 51 | - writing end-user explainers 52 | - writing reference material 53 | - writing test cases 54 | - writing blog posts 55 | - summarizing meetings and decisions 56 | - reference vs end-user 57 | - these are different mindsets 58 | - perhaps different folks 59 | - discussion about trying to make “status updates” more a part of the process 60 | - personal blogs vs/and/or 61 | - lang-team blog 62 | - example: try functions 63 | - begin with establishing the problem: 64 | 65 | 66 | fn foo() -> Result<(), Error> { 67 | bar()?; 68 | baz()?; 69 | Ok(()) 70 | } 71 | 72 | try fn foo() -> Result<(), Error> { 73 | bar()?; 74 | baz()?; 75 | } 76 | 77 | 78 | - iterate over various proposals 79 | - some of the questions that have arisen in the past: 80 | - mental models etc ← can we evaluate this more clearly? 81 | - would scope just be too small: 82 | - error handling in general 83 | - example: error handling 84 | - sketching out the challenges people face here 85 | - finding key examples 86 | - there will likely be a lot of “subparts” here 87 | - first step: establishing a roadmap 88 | - example: traits working group 89 | - would be useful to enumerate what the key examples, problems being solved are 90 | - implementations outside compiler to ‘prove out’ an idea, using procedural macros 91 | - e.g., arguments in main 92 | - doc comments to define `.context()` for errors 93 | - try functions 94 | - Some things we didn’t talk about and could talk about: 95 | - “overall WG procedure” 96 | - how to have controversial conversations 97 | - conflict resolution 98 | - how to manage deeply technical conversations 99 | - how do we select what to do and when 100 | - scheduling breaks, cadence of features 101 | - how much is it ok to miss things :) 102 | - do we want formal staging mechanism and what is it 103 | - (and can we skip steps where appropriate) 104 | - when/how should a working group end 105 | - 106 | 107 | 108 | -------------------------------------------------------------------------------- /working-groups/meta/minutes/2019.06.06.md: -------------------------------------------------------------------------------- 1 | # Meta WG 2019.06.06 2 | 3 | - [Video](https://youtu.be/UYrq3eINGUM) 4 | - [Dropbox paper](https://paper.dropbox.com/doc/Meta-WG-2019.06.06--Aeh5qqFUFXz4Usd_a899bZKGAg-VO3EBc6lEdNunBh6hxGfn) 5 | 6 | # Summary 7 | 8 | We focused on what the output from the "exploration" stage of a 9 | working group might look like. We [sketched out some 10 | examples](https://paper.dropbox.com/doc/Meta-WG-2019.06.06--Aeh5qqFUFXz4Usd_a899bZKGAg-VO3EBc6lEdNunBh6hxGfn#:uid=330091089397131641914243&h2=Error-handling) 11 | for the case of error handling. We settled on a rough outline looking 12 | roughly like this: 13 | 14 | - Problems in and around the space 15 | - describe the problems we are aiming to solve, as precisely as we can 16 | - give representative examples that can be referenced in the solutions 17 | - aim for completeness, even if not everybody agrees it is a problem 18 | - Positives and strengths to consider 19 | - things that are working well which might be “imperiled” by some of the solutions 20 | - or just general things that we want to preserve and why 21 | - Solutions 22 | - describe possible solutions 23 | - what problems do they try to address 24 | - relationships between the solutions 25 | - do they build on one another? 26 | - Unknowns and constraints 27 | - list out concerns, things to be resolved 28 | - Roadmap recommendation? Narrative? 29 | - experiments? in particular, can we use procedural macros, 30 | nightly builds, or other mechanisms to enable experimentation 31 | and try to answer specific questions and ideas. 32 | - this part was the least clear -- how much do we ex 33 | 34 | We looked a bit at the [TC39 homepage][TC39] and the way that it 35 | clearly identifies proposals by stage and had some back-and-forth 36 | about how to compare that with our existing set of [github pulls]. 37 | 38 | [TC39]: https://github.com/tc39/proposals 39 | [github pulls]: https://github.com/rust-lang/rfcs/pulls/ 40 | 41 | # Homework and next meeting 42 | 43 | Before our next meeting, we should: 44 | 45 | - Research the [TC39 process][TC39], for those unfamiliar with it, or 46 | other relevant processes. 47 | - Niko would like to try and apply this exploration to `impl Trait` or 48 | some other example, but this may not happen. :) 49 | 50 | Although this wasn't discussed in the meeting, next meeting I hope to 51 | spend a bit of time digging into other processes to learn more about 52 | how they work. In particular probably starting with Chef, to build on 53 | some "local expertise". --nikomatsakis 54 | -------------------------------------------------------------------------------- /working-groups/unsafe-code-guidelines/NOTES.md: -------------------------------------------------------------------------------- 1 | This file contains summaries from the meetings where the 2 | unsafe-code-guidelines WG synchronizes with the lang team and broader 3 | community. 4 | 5 | - [Update from March 14, 2019](notes/2019-03-14.md) 6 | 7 | -------------------------------------------------------------------------------- /working-groups/unsafe-code-guidelines/README.md: -------------------------------------------------------------------------------- 1 | # Unsafe Code Guidelines (UCG) Working Group 2 | ![working group status: active][status] 3 | 4 | The goal of the Unsafe Code Guidelines (UCG) effort is to 5 | collaboratively produce a "reference guide" for writing unsafe code 6 | that what kinds of things unsafe code can and cannot do. 7 | 8 | - **Leads:** [@nikomatsakis][nikomatsakis], [@avadacatavra][avadacatavra] 9 | - **Meeting Notes:** [All](NOTES.md) 10 | - **Dedicated repository:** [rust-lang/unsafe-code-guidelines][ucg] 11 | 12 | [ucg]: https://github.com/rust-lang/unsafe-code-guidelines 13 | [status]: https://img.shields.io/badge/status-active-brightgreen.svg?style=for-the-badge 14 | 15 | # How can I get involved? 16 | 17 | You will find complete instructions on how to participate in [the 18 | rust-lang/unsafe-code-guidelines repository][ucg]. The conversation is 19 | mostly taking place asynchronously over GitHub issues although we do 20 | also have weekly synchronization meetings and the occasional video 21 | chat. 22 | 23 | - **Zulip stream:** [`#t-lang/wg-unsafe-code-guidelines`][zulip] on Zulip 24 | 25 | [repo]: https://github.com/rust-lang/rust 26 | [zulip]: https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll 27 | 28 | 29 | [nikomatsakis]: https://github.com/nikomatsakis 30 | [avadacatavra]: https://github.com/avadacatavra 31 | [RalfJung]: https://github.com/RalfJung 32 | --------------------------------------------------------------------------------