# T-Style Minutes
###### tags: `minutes`

Meeting Link: https://meet.jit.si/t-style-style-team-task-force

> *****Archived due to hackmd length limits. Continues in https://hackmd.io/lcquVLbdTTiW1oMDTmpn5A#

## 2023-03-29

### Attendance

Caleb (lead, secretary), Michael, Jane (facilitator)

### Agenda

* Agenda consent + Check-in
* Review prior action items
* (Explore) Discussion/questions around perf reviews ~5 mins
* (Explore) Jane to share info and updates efforts around scribe/note-taking ~5 minutes
* (Decide) Approach for establishing policy for formatting of nightly language items
* (Explore) Policy for formatting of nightly language items #urgent #important
* Meeting Check-out

### Minutes

#### Review Prior Action Items

* let chains still pending
* style team edit permissions pending, clarifying questions and discussion about access (caleb has bors perms but not fcp checkbox)

##### Completed

* [x] Caleb to create scaffold of "new" rustfmt stability policy - https://hackmd.io/pEHUiAAeRbCu5rHfzi8A9w

#### Perf Reviews

Started with recap of https://rust-lang.zulipchat.com/#narrow/stream/353175-t-style.2Fprivate/topic/Facilitation.20Performance.20Review

Jane: (in response to question about whether we'd agreed to have these reviews) Not explicitly, but important activity for certain roles, e.g. leads, and am advocating for it. Want to practice within t-style before pushing more broadly across the project.
Jane: Different context in open source/volunteer vs. corporate setting. Review for lead role should have association with goals of the team, not necessarily true for other roles (like facilitator). Also overlap with one of the motivators applicable in corporate settings of providing feedback and supporting growth
Jane: A formal review setting for the facilitator role not as critical as it could be for other roles, especially since we have a weekly check-out process. Not necessarily opposed to skipping the formal review because of the check-out, although performing the exercise could be useful for sociocracy work
Michael: Agree dedicated session probably not as necessary or helpful. However, there may be some feedback that doesn't tend to pop-up in weekly checkout (e.g. observed patterns or trends) but it's probably less important.
Caleb: i think too much (expand after meeting)
Jane: It is more formal, but still balance the amount of input/effort required, which should be fairly similar to check-out. Candid, off the top of the head thinking is fine. Not necessary to spend days of prep work and analyzing historical context (e.g. reviewing all prior minutes)

#### Scribe/notes-taking update

Scribe should be able to interrupt the meeting to get their needs met (as a scribe) -- phrase to use is "point of order".

Michael: Anyone should be able to raise point of order, not just scribe. Scribe most likely to need it, but valid reasons why others may need to from time to time
Jane: Agreed, action item to update policy doc with above

Jane: More input from project leadership, other teams interested in scribing/note taking. W3C processes shared by Manish
Jane: few takeways, want to grow skills and experience, but also still interest in obtaining dedicated scribe resources. would be good to make it an option for teams to choose whether they need/want the support, or practice/implement internally
Jane: Ongoing dialog with foundation relative to team meeting specifics (cadence, etc.) to help inform resource needs. Received some insight and concerns from a work colleague relative to some challenges and pitfalls from an external scribe resource, will keep those in mind as we try solutions within the project
Caleb: happy to hear it
Michael: Agreed, challenges are certainly experienced elsewhere in the project, looking forward to some resolution/assistance for t-style

#### (Decide) Approach for establishing policy for nightly style

Jane: Think that policy should be iterated quickly, low-overhead and it's a reversible decision. Making policy decisions + getting feedback is more effective than iterating on a perfect policy.
Jane: Who owns the policy and who needs to consent to it? How does this policy link rustfmt + t-style? Guess that it's T-style advising a rustfmt policy.

Caleb: Rustfmt owns stability policy for rustfmt. T-style owns the governance artifact of rustfmt, so circular relationship. Agree with Jane's position, and the lack of a specification in this area means that T-style can establish guidelines without forcing rustfmt to break existing guidelines. This gives us a path forward, do still want to update the policy that incorporates on these decisions -- owned by rustfmt but will have T-style input.

Michael: Agree that eventually needs to be formalized, but glad there's no existing policy dictating formatting for new syntax

Jane: In favor

Caleb: T-style should articulate our opinion somewhere that can be pointed to in the interim.

Jane: Proposal -- should go in the policy document. Michael should write it, how T-style proposes nightly style guides and we want to be supportive both towards T-rustfmt + T-compiler/lang.

Michael: No strong opinion, don't mind.

Caleb: what lives in r-l/rust is the style guide, formatting constructs, principles, etc. When I heard policy doc, I was thinking of Jane's PR establishing policy. Slight preference towards nightly syntax living in the style guide.

Jane: No objections to living in the style guide. Policy documents that live in our repo that'll get moved to a centralized policy repo (as part of governance RFC) should also link to the other policies of the team, so we'll want to link to the style guide from our team's policy living in the t-style repo.

#### Check-out

:sunglasses:

## 2023-03-22

### Attendance

Caleb (lead, secretary), Michael, Jane (facilitator)

### Agenda

* Agenda consent + Check-in
* Review prior action items
* (Decide) Policy for formatting of nightly language items #urgent #important
* (Decide) complete discussion on https://github.com/rust-lang/fmt-rfcs/pull/175 (team policy and charter) #important #blocked (goal: )
* Meeting Check-out

### Minutes

#### Review Prior Action Items

##### Completed

* [X] Caleb to add tracking issue for style evolution in r-l/rustfmt

r-l/rust has manual permissions, not based on r-l/team. can ask if infra will add t-style with triage (or whatever issue edit perms) to t-style

*Action Item* - Michael to request infra to give t-style edit permissions in r-l/rust. Caleb may need to thumbsup, also potential for some thumbsup from t-lang.
*Action Item* - Caleb to edit r-l/rust tracking issue with link to rustfmt issue once perms given

#### Policy for formatting nightly language items

Michael: document created and shared proposing approach for handling new nightly syntax/features to try to get rustfmt support added earlier in the process to facilitate experimentation.
Caleb: t-style and t-rustfmt, rustfmt RFC around stabiltiy guarantee
Michael: Want to be cognizant of capacity and load, willing to help with the rustfmt stability RFC to help move things forward
Jane: Suggest we summarize discussion with blockers and next steps to both provide clarity and maps out next steps
Caleb: Yup, that makes sense. Notes that could've done so beforehand
Michael: No worries, and not necessary
Jane: Propose shift of remaining time to work on this. Thoughts/any objections?
Michael: Sure, and while working on doc can skip capturing of detailed notes separately here since they will feed into the doc
Caleb: Yes please

[working on doc](https://hackmd.io/H1c6_DkcT3-yB6wUm40jiA)

## 2023-03-14

### Attendance

### Agenda

* Agenda consent + Check-in
* Review prior action items
* (Decide) Policy for formatting of nightly language items #urgent #important
* Meeting Check-out

### Minutes

#### Review Prior Action Items

##### Completed

## 2023-03-08

### Attendance

Caleb (lead, secretary), Michael, Jane (facilitator), Josh

### Agenda

* Agenda consent + Check-in
* Review prior action items
* (Decide) Backlog prioritization (urgent/important)
* (Decide) Policy for formatting of nightly language items #urgent #important
* Meeting Check-out

### Minutes

#### Review Prior Action Items

Caleb: Still WIP on style guide PR for let chains and deciding style_edition tracking issue in r-l/rustfmt

###### Completed

* [ ] Caleb to follow up asynchronously on V2 item: https://github.com/rust-lang/rustfmt/issues/5577#issuecomment-1331628360
* [ ] Caleb to do final pass through list of previously reviewed items to confirm there are no additional v2 items that need more review

#### Backlog Prioritization

Jane: review backlog top to bottom

##### Team Policy Item
Josh: Important but not urgent
Jane: Agreed

Consent: Important but semi-blocked

##### Proposed formatting changes
Jane: Important but not urgent
Josh: Clarification question on definition of urgent. These are time sensitive items but nothing horrible happens if not addressed immediately.
Jane: Urgent: associated with other timelines, others are blocked. Important: can refine as a group, but compare against our goals and whether an item is moving us forward through goals (including goals not necessarily explicitly codified yet)
Josh: Suggest that this item is important relative to goal of shipping 2024 style edition. There is an associated timeline with that goal, but it is fairly far out; somewhat urgent but not immediately pending/urgent.
Jane: Agreed
Consent

##### Restrictions RFC
Jane: where is this in dev/what's the timeline
Michael: Still in progress, we've commuicated ask. Will be a while before stabilization
Jane: Suggest this is not urgent, but is under our responsibility as a team
Josh: Proposal for a new backlog item. Policy for formatting new items
Jane: Asks if this has ties to other teams like lang, establishing relationship around stabilzation
Josh: Partly, but t-style and t-rustfmt behavior here for nightly-specific contexts.
Josh: Would be good to have a policy around formatting for nightly-only items. Also important but not urgent. Should be covered before individual items
Jane: Actually feels this is urgent, as this will keep popping up.
Michael: Also feels urgent. New syntax added all the time. Having the ability to do formatting for let chains prior to the style being thoroughly "locked in" would have been very beneficial
Jane: Agreed

Consent: Restrictions RFC is Important-but-not-urgent, nightly policy urgent

Michael: Question around highligting backlog dependencies
Josh: Preemptively plans a revolt if Jira were to make an appearance
Group jokes about tabs vs spaces debate. Laughs were had

##### Dyn Star
Michael: Not important, not surface syntax. Can't run rustfmt on ui tests for dyn star, not big deal (esp. compared to e.g. Restrictions)
Josh: Important because anticipated to eventually be surface syntax, but fine with deprioritizing until RFC proceeds
Michael: Notes the prior item about temporary nightly style/behavior relevant in this context as well

Consensus: blocked, not urgent, not important now but suspect it will be in the future. deprioritize

##### Empty Match Arms
Josh: Important. Has breaking formatting implications so must be edition bound and there is associated timelines, likely 2024 style edition
Jane: No concerns/objections
Consensus: Important

##### Macros
Caleb: summary
Josh: Propose we split, treat inline assembly separately from more holistic macro question. might want to include for 2024, same for macros but latter has more blockers and points of consideration (e.g. trailing commas)
Josh: Both are important, one has prerequisites
Jane: Agreed, asks whether there are any thoughts/objections

Consensus: Agreed, both important.

#### Decide policy for formatting nightly changes

Josh: Topic has been discussed already. One policy would be as soon as new feature added to nightly compiler, then we can start adding formatting to rustfmt that will format that feature. That format is unstable until feature is stable, reserves right to change formatting. Nightly users of feature accept formatting may change, but we won't gratuitously change formatting.
Josh: Big ? on policy: "*how* does someone get formatting of nightly items". Is special directive needed, or does it work OOTB because you're using nightly rustfmt? Does it interact with style editions at all?
Michael: Don't necessarily think users need to worry about running a nightly rustfmt version (caleb?). Code will be rejected still if not using nightly rustc. Not worried about users formatting code the compiler won't accept
Jane: If not using version of the compiler toolchain that works with new feature, then wouldn't expect it to format. wouldn't expect older versions of compiler to know about new feature. Not going to enable nightly features without using nightly toolchain
Michael: Similar to compiler changes (GAT Stabilization process moved where clause). Changes can break old compilers. Running older rustfmt versions won't recognize new features
Caleb: rustc_bootstrap
Jane: question about using unstable features
Josh: rustfmt noticably different than rustc. rustc can easily add nightly feature flags, code only run by nightly compiler, can be skipped by rustc but rustfmt has to do _something_. want to avoid flapping? where stable/nightly rustfmt do something different
Josh: we don't make any stability guarantees with nightly, but still need a reasonable workflow. argument for stable rustfmt needing to leave nightly features alone. not sure if it can reliably recognize what needs to be left alone due to existential knowing the unknown. rustc stable knows about nightly features that can't be used on stable, rustfmt equivalent would be "i know about this but can't format it because that's nightly rustfmt's job"
Michael: Good point (flapping issue). Best compromise to say "where possible". New syntax is not just positionally unstable but rustfmt could do nothing. David Tolnay has a config nightly crate, so users do sometimes gate nightly syntax behind a cfg attr. Scenarios more important than initially suspected
Jane: To push back in the other direction, how high a risk is it for a period of time for flapping to exist? Policies should permit adjusting on the fly, nothing is irreversible.
Josh: Concrete proposal - in general, rustfmt nightly needed for nightly features. newer nightly might do better formatting, if using nightly features use nightly rustfmt. best effort made to avoid flapping. degree of best effort is not style's purview, quality of implementation issue. can do better but not a bug if we don't
Caleb: want to digest this before comitting to anything.
Jane: working with foundation on hiring minute takers
Josh: sidenote, happy to collaborate on that effort wrt to what else could be covered by that role, hoping for not strictly a scribe, ideally some level of coordination too, mild degree of project management skills, drafting occasional blog post.
Jane: happy to chat, good idea, will take offline
Jane: (recaps Josh's proposal) Not considered a failure if there are issues in the nightly formatting. My feeling is this is great start. Do anticipate that as we go along the policy can and will be refined, though perhaps not. Could hook into existing logic around features. No objections, no concers
Caleb: clarifying rustfmt's lack of info
Michael: Feature gate validation happens post AST production stages in compiler, agrees rustfmt wouldn't have that info from the compiler. Could potentially do some work to make that available
Jane: curious if command line args are available
Michael: Will have to check parse session to see if it's the nightly compiler
Caleb Nods about parse_session usage in rustfmt
Jane: Wondering what is next, Caleb needs thinking time (Caleb nods again). Not sure what we should do next
Josh: Believe 5 minutes is enough time for empty match arm backlog item. Can give Caleb time to process
Jane: Counter proposal: that one isn't urgent, enjoys breaks and reclaiming time and wonders if we should wrap up early. Could go straight to check out
Michael: Don't mind discussing but have an emptier schedule than others
Josh: No objections, notes we have a 5 minute early exit baked into the meeting, but also acknowledge it's not urgent so fine with giving time back
Jane: Content to see what we can accomplish in the time

#### empty match arms
https://github.com/rust-lang/style-team/pull/147

`{}` vs `()`

Josh: Only reason unit works is for a match arm being used for control flow without returning a value. Braces work the same way, and the return result is also a unit. Unit explicitly comes across as I am returning a value. Braces indicates control flow block that does nothing, is important implementation detail of Rust, but not something typically thought about/intuition for developers.
Josh: I believe braces are obviously right solution. Need to do this in a style edition, though, to avoid a breaking change to formatting.
Michael: Maybe not fully in agreement with unit vs braces argument because match can also be used in expression position. Returning unit indicates explicitly not doing anything meaningful. I like braces aesthetically.
Jane: finds Michael's reasoning somewhat compelling. Wonders if we should have position-dependent formatting, questions whether it's a logical. Initial reaction was strong preference for braces. Wants default style to be intuitive and not require additional thinking, especially during earning learning stages, wants to avoid "why is this turning into an empty tuple" questions.
Caleb: Honestly don't care much, would rather have an answer so rustfmt has direction. re Jane's question about position, but we do have existing rules in style guide that are dependent on position. There is precedent.

## 2023-03-01

### Attendance

Caleb (lead), Michael(secretary), Jane (facilitator), Josh

### Agenda

* Agenda consent + Check-in
* Review prior action items
* (Inform) governance RFC posted, representative selection (2 min)
* (Inform) t-rustfmt +1 on giving t-style triage perms in r-l/rustfmt repo (1 min)
* (Inform) rustfmt let-else support (1 min)
* (Explore?) does t-style have pov on let-else treatment as "control flow" by rustfmt (5 min max)
* (Explore) Continue analyzing rustfmt version=Two differences for vNext Style Guide Edition (https://github.com/rust-lang/rustfmt/issues/5577) https://hackmd.io/l1wB1homSee1pmRdT1xB8g?both#2023-03-01 (whatever time is left)
* Meeting Check-out

### Minutes

#### Review Prior Action Items

Michael: Left a comment on the multiline block PR discussed last meeting - https://github.com/rust-lang/rust/pull/102432#issuecomment-1442325932
Caleb: Verdict shared on PR - https://github.com/rust-lang/rust/pull/106074#discussion_r1118126906
Caleb: let-chains style guide PR still pending
Caleb: style evolution tracking issue still pending

###### Completed

* [x] Michael to share verdict on PR: https://github.com/rust-lang/rust/pull/102432
* [x] Caleb to share verdict on PR: https://github.com/rust-lang/rust/pull/106074 (https://github.com/rust-lang/rust/pull/106074#discussion_r1118126906)
* [x] Michael will reach out to infra to request rename of r-l/fmt-rfcs to r-l/style-team: https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Moving.20rust-dev-tools.2Ffmt-rfcs.20to.20rust-lang.2Fstyle-team/near/329603197

#### Governance RFC Posted, Representative Selection

Josh: Officially posted RFC 3392, take a look. Raise concerns with T-style's parent team, T-lang (Josh or Niko). In the process for rep. selection for representing T-lang and all subteams. Representative can theoretically be from a sub-team, but a member who has scope to represent T-lang should (probably) be on T-lang :)
Caleb: Thanks for the effort put into governance reform

(Some discussion about who might wish to represent which teams.)

#### T-rustfmt +1 on giving T-style triage perms in r-l/rustfmt

Caleb: Suggestion from previous meeting about whether T-style should get perms on rustfmt repo?
Caleb: Problem is that rustfmt permissions are managed manually (not via rust-lang/teams).

Michael: Why aren't we using teams repo?
Caleb: No way of setting other than developer role
Josh: Worth at least checking, I *think* this capability exist, and if not, Ryan or one of the other teams repo developers could probably add it if we asked :)

Caleb: I still have admin permissions for other reasons, they agreed not to take it away. Agree with mechanism to grant triage role via teams repo.
Jane: Interpretation that the manual permissions were being handled for some other barrier, but otherwise no reason to fix it.

Josh: What does "triage" permissions mean? Specifically would like to make sure we can add comments.
Caleb: Will double check.

ACTION ITEM: Caleb should add T-style triage permissions for r-l/rustfmt

#### rustfmt let-else support

Caleb: Done, couple of comment-related edge cases. Question has arisen relative to rustfmt config options being applicable. Does T-style want to be informed/answer questions having to do with rustfmt config options?

Josh: In vast majority, T-style shouldn't care about extra options. One exception case would be style principle where rust code should *never* be formatted like this. Suspect rustfmt would share our taste with T-style in these cases though.
Jane: Agree with Josh's perspective that we care about the defaults. Style probably shouldn't be deciding though.
Josh: +1 for "advise, don't decide"

Jane: Caleb, do you feel like T-style exists to separate implementation from style decisions. Should we be deciding rustfmt questions when asked?
Caleb: T-style consults

Josh: (In general, we should pay attention to whether we're answering the question that's asked; in this case we assumed (correctly) that rustfmt wasn't *wanting* to hand off this responsibility, but good to make sure.)

Michael: When rustfmt asks a question should frame whether they are asking whether t-style cares or whether they want t-style to make the decision, and in general the "does t-style care" answer will likely be no
Jane: T-style is here to support rustfmt to take the work that burned some of the rustfmt folks. Reach out if rustfmt thinks it could help them! We're here to help (prevent) bikeshedding when wanted.

#### V2 style changes reviewed

ACTION ITEM: Caleb to clarify what V2 item needs to be clarified here: https://github.com/rust-lang/rustfmt/issues/5577#issuecomment-1331628360

ACTION ITEM: Caleb to do final pass through list of previously reviewed items to confirm there are no additional v2 items that need more review

#### Post-hoc

Jane: Should we gather up and compile action items before the meeting is over?

(ran out of time, we should discuss next week)

## 2023-02-22

### Attendance

Caleb (lead), Michael(secretary), Jane (facilitator), Josh

### Agenda

* Agenda consent + Check-in
* Review prior action items
* (decide) t-style posture on unused_braces lint extension and application to macro args introducing some level of conflict with formatting rules https://github.com/rust-lang/rust/pull/102432
* (explore) formatting rules for restrictions/[rfc3323](https://rust-lang.github.io/rfcs/3323-restrictions.html) - https://github.com/rust-lang/rust/pull/106074
* (explore) formatting rules for pattern types - https://github.com/rust-lang/rust/pull/107606
* (explore) formatting rules for unnamed struct and union fields - https://github.com/rust-lang/rust/pull/99754
* Meeting Check-out

### Minutes

#### Review Prior Action Items

Caleb: all my action items are still pending
Michael: Repo rename request has been made

##### Completed

##### Review PR 102432 - unused_braces

https://github.com/rust-lang/rust/pull/102432

Caleb: insert your summary
Josh: Seems fine, don't feel strongly
Michael: Seems strange that the fix entailed addressing single macro. Potentially on Caleb's side. Reservations about making unused_braces more complicated. Not a particularly strong opinion though
Jane: Feels really strange to have a lint contradict rustfmt behavior, seems like a cross organization bug. Fixing a specific nstance of triggering the conflict means we're guaranteed to see in the while. Match-like macros for handling errors. Don't have strong opinions. Unclear on how much formatting we want to do within macros. Red flag when formatting is applied in macro context. Concerned about potential risk in macros
Caleb: Hears perspective, have had shades of many of them. Think there's a more core question: style guide prescriptions for macros, if anything? Relating to this current PR, feel better about PR going forward not being applied to macro args.

Michael: Likely more comfortable if macro args were skipped, though macro bodies are typically what's skipped. Will have to check if it's feasible in this context (depends on whether lint is applied against AST or HIR)
Josh: long term mechanism for identifying macros as straightforward, not impacted by adding/removing commas, braces, etc. Noting "I'm not wierd :)"
Jane: Want to confirm whether this is macro calls or bodies
Michael: TLDR - it looks possible

Verdict: Leave a message on PR indicating caution against potential macro impacts. Style team preference to skip application on macro args.

*Action Item*: Michael to share verdict on PR

##### Review rfc3323/PR 106074 - restrictions

https://github.com/rust-lang/rust/pull/106074

Josh: Shared background and summary of RFC
Josh: Straightforward, prefers formatting to be shipped with implementation. Only potential edge cases are around wrapping. No line wrapping between parens

Michael: Notes `impl(in path::path)` scenario and whitespace
Josh: Was going to ask about line wrapping before closing paren

https://github.com/rust-lang/rust/pull/106074/files#diff-61f272031a50579fed10d1b641e44bcca5be77a4184f14f82245620055b16dfa

Jane: How involved does the style team need to be? Would like for style team to rubber stamp, unless there's an obvious open question. Style team should be bikeshed police. Give us your concerns, and we can make a decision. Otherwise, this one we don't need to be involved.
Caleb: One area where I'd push back is if we don't have explicit rules in the style guide, there's no source of truth for what rustfmt is supposed to be doing. Always been rules then rustfmt implementation. Otherwise authors of PRs that include new AST constructs are able to decide their own formatting, community isn't reviewing the impl.
Caleb: (somewhat tangential) Rustfmt team needs to publish a new RFC wrt stability for new syntax to figure out, and codify, a process and expectations
Jane: Good point, where's the balance? Potential policy discussion/question: how do coordinate style discussions neceesitated by implementation PRs. In non-controversial/simple cases, go forward and then plug into the style guide (afterwards?). What's the flow, would PR author

Caleb: 20k foot view, rustfmt isnt allowed to change its mind in general. Anecdotal posture shared previously around rustfmt behavior wrt new syntax is "eh" and "there's some flexibility". Not comfortable with that posture as it's too fuzzy, so yes, we'd need to RFC with some clarity to the policy of handling new syntax as part of its implementation & stabilization.
Caleb: preference is to give feedback to this PR author to apply the common initial rustfmt "do nothing" behavior, asks Josh for thoughts given concern raised earlier

Josh: Objection is to never applying any rustfmt behavior, if we temporarily do the "leave formatting" and then apply formatting later that would be fine
Michael: Frustrations/concerns with rustfmt not being able to change formatting for unstable syntax. We should be able to format try blocks differently. rustc changes to unstable constructs also has CI-breaking behavior
Jane: move rustfmt stability convo async
Josh: would like to have full discussion about formatting unstable features and syntax
Jane: would there be style guide changes for these rules?
Josh: expect there would be small ones
Jane: who would be responsible for updating the style guide?
Josh: style team or contributor, not rustfmt team
Jane & Caleb: agree

Verdict: (decide-ish): Will ask PR author to revert to do-nothing behaviro for rustfmt. Style team will do a quick sanity check on formatting, and rustfmt team will subsequently add back formatting behavior

*Action Item* - Caleb to post response on PR
*Action Item* - Add Backlog item to review formatting rules for restrictions

#### Review PR 107606 - Pattern Types

https://github.com/rust-lang/rust/pull/107606

Michael: Verdict = same decision as last one, though this PR is unlikely to land any time soon
Josh: agreed
Josh: This is an MVP. Syntax is least final thing. Concept of type restricted by this pattern is very likely to be added, with widespread support. Details like keywords, syntax, etc. is based on the hypotehtical `is` keyword, we don't have that keyword yet, etc. extremely not final. At best we could brainstorm potential formatting, but not worth investing much time and effort. Main formatting question would be around line breaks given patterns how long patterns can get

Verdict: (decide-ish): Will ask PR author to revert to do-nothing behavior for rustfmt if this proceeds beyond proof of concept state.

## 2023-02-15

### Attendance

Josh, Jane (Facilitator), Caleb (lead/secretary)

### Agenda

* Agenda consent + Check-in
* Review prior action items
* (explore) continue review of rustfmt v2 formatting items
* classify as: bugfix, obvious want, or needs further discussion?
* https://hackmd.io/l1wB1homSee1pmRdT1xB8g?edit (separate hackmd from last week)
* Meeting Check-out

### Minutes

#### Review Prior Action Items

##### Completed

* [x] Jane to make a PR against T-lang website to link T-style calendar

#### Continue review of rustfmt v2 formatting items

See separate hackmd https://hackmd.io/l1wB1homSee1pmRdT1xB8g?both#2023-02-15

Josh: may want to document that rustfmt modifies code that takes advantage of rustc changes. would be surprised if rustfmt changed code to utilize `let else`. But technically this change (nested tuple access spaces) does increase the MSRV
Jane: Asks for clarity on this point

Josh: won't take advantage of new rustc features outside of edition
Jane: theoretically a surface area in an edition. only first set of features within an edition that can be applied. msrv relationship with edition, and may be too broad
Josh: asks for clarification
Jane: using example of nested tuple access with spaces. imagine we already have rustfmt editions, 2021 edition was the one where the rustc lexer bug was fixed, we had a rule in the style guide then if style_edition=2021 then rustfmt + style guide can take advantage, but changes could be introduced/supported in an edition that if taken advtange of could still increase the MSRV (more info/carity/correction needed)

General consensus that this is unlikely to happen in practice, and could potentially be guarded against via consideration when applying changes to the style guide

## 2023-02-08

### Attendance

Michael (minutes), Jane (facilitator), Josh

### Agenda

* Agenda consent + Check-in
* Review prior action items
* (explore) review the next batch of rustfmt v2 formatting items
* classify as: bugfix, obvious want, or needs further discussion?
* https://hackmd.io/l1wB1homSee1pmRdT1xB8g?edit (separate hackmd from last week)
* Meeting Check-out

### Minutes

#### Review Prior Action Items

Caleb: style guide changes for let-else nearly done, PR will be up tonight
Josh: Note filed to add t-style calender item to agenda for t-lang meeting

###### Completed

* [x] Michael will create a T-Style hackmd group, change permissions so only T-style can edit minutes

## 2023-02-01

### Attendance

Caleb, Michael (minutes), Josh (facilitator)

### Agenda

* Agenda consent + Check-in
* Review prior action items
* (Explore) Analyze rustfmt version=Two differences for vNext Style Guide Edition (https://github.com/rust-lang/rustfmt/issues/5577)
* Meeting Check-out

### Minutes

* check-in was had
* backlog was gone over

#### Review Prior Action Items

##### Completed

* [x] Caleb to open PR in r-l/rust adding let-else rules to Style Guide - https://github.com/rust-lang/rust/pull/107312
* [x] Josh to announce T-style calendar during T-lang meeting once it's created

#### Rustfmt v2
* Josh: Noticed new style changes added recently
* Caleb: T-rustfmt needs to go through and note the subtle differnces in these examples

* Josh - Starting points: Link to the individual items and have an item per comment on the issue

* Caleb - Separate hackmd?
* Consensus - yes

Separate hackmd: https://hackmd.io/l1wB1homSee1pmRdT1xB8g?edit

* Caleb - there might be two camps:
* Rustfmt failure (a bug that cant be fixed except across an edition) but doesn't need to be in the style guide
* An improvement to style

## 2023-01-25

### Attendance

Caleb (secretary/lead), Michael, Jane (facilitator), Josh

### Agenda

* Agenda consent + Check-in
* Review prior action items
* (Decide) potentially renaming fmt-rfcs repo
* (Decide) complete discussion on https://github.com/rust-lang/fmt-rfcs/pull/176 (team policy and charter)
* Meeting Check-out

### Minutes

#### Review Prior Action Items

Caleb: style guide changes for let-else nearly done, PR will be up tonight
Josh: Note filed to add t-style calender item to agenda for t-lang meeting

###### Completed

* [x] Caleb to ensure team decision reached on let chains

#### Name of rust-lang/fmt-rfcs repo

Josh: fmt-rfcs historically used to capture specific style proposals in a templated manner, history around formatting discussions and decisions. With new charter and procedures, some formatting items (proposals, etc.) would be done directly in r-l/rust where style guide lives while other more involved/complicated ones may still be done in fmt-rfcs. open to renaming to style-team.
Josh: Do we have a new/separate repo for style-team items with links to fmt-rfcs
Jane: We need a scratch repo, used to interacting with T-libs repo. Cool to have a place to throw stuff. Policy would be useful to put in this repo. No strong opinion on new repo vs renaming, seems easier to rename since it exists already.
Josh: Only downside is that there are open issues on the repo, would need to be triaged and cleaned. Two of em are ours, two of em are stuff that will need to get moved to r-l/rust. After that, let's rename.
Caleb: Question around process -- some things might get proposed in r-l/rust, but we may need a separate repo for lengthier discussions around more complex items. If that's correct, is the intent that we have elongated discussions in the T-style repo?
Josh: Yes, even if we rename to style-team we can still use this for formatting/style rules. Small tweaks can be proposed directly in r-l/rust, larger should go to fmt-rfcs/style-team repo. Dividing line will be fuzzy but think we can manage.
Michael: Speaking for perspective of compiler team repo, discussions still happen in the team repo regardless of the name.
Jane: Somewhat haphazard where issues live in libs vs. rust repos, but not really problematic in practice. There are still open questions around issue trackers live with backlogs. Having separate repo with less noisy provides more flexibility and increases ability to get things done. Can decide on a case by case basis where an issue should reside.

Decision: Consensus to rename rust-lang/fmt-rfcs to rust-lang/style-team

**Action Item** Michael will reach out to infra to request rename

#### Team Policy and Charter

Jane: One discussed change still missing relative to not relying on syntax highlighting.
Caleb: Do we need this textualized inline in team policy/charter or can we link to the principles enumerated in
Jane: Think it's wortwhile to also highlight the impact of principles in addition to the principles themselves, could potentially be linked depending on the exact text but may still be worth incorporating inline.
Jane: Goal of not-overthinking policies, let's see what's in the way of moving forward.
Jane: Do need to define feedback dates for operator and secretary role. Suggest using a similar schedule to those proposed for other roles but potentially with a day offset (Wednesdays?).
Jane: Questions on secretary role description, starting point taken from sociacracy where secretary is interpreter of policy, but understand concern previously raised by team members about having the secretary being the sole authoritative inteprretor
Jane: Okay with removing that language, but somewhat curious about the impact about not having a designated person in that role should the situation occur.
Michael: Question about the comment around immediate resolution around policy interpretation. The real-time interpretation function is valuable, the concern is about the lasting/finality of the interpretation being designated to a single person. Perhaps the secretary could itnerpret in the moment but then have the team agree to the more lasting interpretation?
Jane: Delegation is useful to ensure expedient resolution, even for issues/ambiguities that are uncommon, but still need a broader and amortizing interpretation. If there's any issues with the individual in the role, that could be addressed
Caleb: Might feel more comfortable with a "for instance", but recognizes the distinction of having someone in the moment to move things forward, but they're not going to have an authoritative, sole-decision-making power. Not a monarch. Happy to consider, just want to see what it looks like in text.
Josh: Happy to work with this if changed from "only" interpretor to "default"
Josh: Think it's perfectly fine to not imply this role is the arbitor of all things, intent is not to have this person's word carry most weight in the event of disagreement. Not a diffusion of responsibility, not everyone's job and therefore no one's job. We can, and should, still operate by consent.
Josh: Frame it as the default person responsible for arbitration
Jane: I think, it sort of implies that in the event of an ambiguity this person suggests an interpretation to move forward with in the moment. However, others can still object and flag the policy concern as a recurring issue that needs attention and resolution. Could result in deferral of topic at hand so that policy concern can be addressed and resolved. Does this align?
Josh: Roughly. We still have to consent to interpretation, but someone still has the responsibility to be the default person to make/propose an interpretation. That should avoid enshrining any concentrated power/authority with one person and make it more of a facilitation role in the event of differing interpretations
Jane: Recent discussion from governance work, splitting secretary and scribe into two different roles held by two different people. This seems applicable here as well, especially as Caleb has expressed not wanting to be policy interpretor which I (Jane) wouldn't mine, but I wouldn't want to take notes
Josh: Any objections to changing policy to split secretary and scribe roles?
(no objections voiced)
Josh: Any objections to making Jane the first secretary?
Jane: (Facilitator voice) wants to object to using the meeting as the forum to make the role selection, would like to try some alternative methods
Josh: No objections to deferring. Was just making a proposal attached to a proposal
Jane: Resolution: secretary and scribe role will be split. Secretary will be interpetor of policy, scribe will be responsible for minutes and tracking of minutes as well as agenda preparation and backlog
Josh: Only thing secretary would be responsible for by default would be interpretation
Jane: Tracking evaluation dates should also be associated with secretary role. But could go either way
Caleb: Where are we placing the responsibility for agenda? Secretary or scribe?
Jane: Scribe. ~~Backlog and~~ evaluation date would be responsibility of secretary.
Josh: Question about evaluation and evaulation dates we haven't fully discussed yet, but if that's a thing then it should be under the purvivew of the secretary
Jane: Going forward we should aim to do as much policy work as we can async. Will go make the changes we've discussed in the PR

## 2023-01-18

### Attendance

Caleb (secretary/lead), Michael, Jane (facilitator), Josh

### Agenda

* (explore) discuss what meeting check-ins look like
* agenda consent + check-in
* review prior action items
* (decide) let chains
* review code examples from rustc against proposed style option
* review expr kinds for any additional operand variants that could fall into the "same line" formatting rules (e.g. `Unary`)
* Review comment from estebank and make sure we're considering that possibility: https://github.com/rust-lang/fmt-rfcs/issues/169#issuecomment-1386312478
* (in case it's helpful) https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/enum.ExprKind.html
* (decide) any outstanding discussion/elements needed for team charter or policy
* time permitting, (explore/decide) review rustfmt v2 formatting differences and categorize (include in next style edition, exclude, or more discussion needed) https://github.com/rust-lang/rustfmt/issues/5577
* Meeting Check-out

### Minutes

#### Misc/AOB

General procedure, action items with associated PRs can be moved to completed once PR is opened and PR resolution can be handled in-repo

#### Check-in meta (what meeting check-ins should look like)

Caleb: Not really sure what the check-ins were supposed to be
Jane: Shared info (https://www.sociocracyforall.org/meeting-format/) around how check-ins are used in one type of meeting format
Josh: Shared benefits experienced from utilizing check-ins in other team meetings
Josh: Sequencing should ensure check-in occurs before agenda consent to allow for opportunity to adjust agenda accordingly

Agreement to utilize a check-in process quick round/opening to share initial thoughts, state of mind, etc. prior to initiating meeting. This will similarly not be recorded absent consent & need to capture as an action item or backlog item.

#### let chains
(reviewed) rustc examples captured in notes from last meeting

Josh: `!ident` should also be incorporated into option, potentially dot/member access (`ident.ident.ident`) too
Jane: Agreed. Don't feel strongly on dot access, but lean towards yes. Fine either way
Josh: Main argument against dot access is that it's effectively a slippery slope. Unless we go down the route of trying to define a "simple" criteria that incorporates more (which we agreed to not do last time)
Michael: Agreed, also don't feel the need to do many things other than `!`
Caleb: When we talk about unary expressions, are we excluding deref (`*`) and negation (`-`) operators intentionally, and if so, why?
Josh: A response and a question -- negation is only pertaining to overloaded operators whose `type Output = bool`, have a hard time treating that as a case we should care about. But `*` or really any stack of unary prefix operators
seems fine.
Caleb: Also curious if anyone feels like `.await` and `ident?` should be included
Jane: Less interested/persauded on await & try. Not too concerned with edge cases nor any evil code shenanigans :). Fine with incorporating the full set unary operators for allowing the chain to be single line
Michael: Not a fan of allowing single line with `.await` nor `ident?`, open to allowing unary
Josh: Almost all the time we don't `.await` or `?` a variable in an `if`, it's usually `?` or `.await`ed when it's assigned to a variable. Seems not especially important for that reason. Shouldn't ever write `!ident?` anyways, once parens are added it's going to be broken. Seems bad to mix them because of grammatical ambiguity.
Josh: `.await` and `ident?` seem less important because you don't usually have those already in a variable (more likely to get them by calling a function), and if you do you could `?` or `.await` when you call that and put it in a variable.
Josh: what about `ident && !ident && let ...` , is the rule "one clause" or can you have any number of clauses before the let?
Jane: Example really hits on the complexity and how many scenarios we could have to consider
Jane: Earlier convo reminded of temporary lifetimes and locking issues [jane could add if she wants (she did, click me for the related issue)](https://github.com/rust-lang/rust/issues/93883). But even more hesitant to incorporate await for that reason.
Josh: Go with One clause rule, `a && b && c` is harder to defend due to complicating rules further.
Josh: Asks if Caleb would be willing to propose precise text to the style guide given familiarity with edge case and more (recent) familiarity with text
Jane: Suggests we review Esteban's recent comment prior to final decision
Josh: One aspect of comment is around formatting rules, first few items relate to formatting let similar to let clause with reference to benefit of syntax highlighting, second topic was around brace placement and preference for same line, third set was more about rustfmt specifics
Caleb(unspoken): Will take the responsibility to address the rustfmt specifics of Esteban's comment, likely in chat vs in-issue to avoid going OT
Jane+Josh: Our existing list of principles already highlights that style guide presecriptions should not rely on syntax highlighting
Jane: We should still decide let chains direction today

**Action item for Caleb to follow up with members to ensure decision is reached**
**action item for caleb to incorporate proposed rule into guide text**

Josh: Asked if we're all still in favor of option 5 with some potential additional discussion around brace placement
Jane: Generally yes but want time to review Esteban's comment in detail
Caleb: Yes
Michael: Yes
Jane: Not a big fan of having braces on their own line
Michael: Brace placement should just work just like regular `&&` breaking in `if`, notes there are existing cases where this occurs
Caleb: Echoed/agreed that this aligns with existing aspects of style guide
Josh: Agreed, decision made

Proposed rule (not intended as final style guide text, needs tweaking to fit within the style guide and not unintentionally diverge):
In a let chain, always break after a `let` clause. Always break before the `&&` before a `let` clause *unless* the entire `if` consists of an `&&` with two clauses, the first of which is `ident` or `!ident` or any number of prefix unary operators applied to a single ident, and the second of which is a let clause; in that specific case, if the entire `if` condition fits on the same line as the `if`, write it on the same line as the `if`.

#### Completed Action Items

* [x] Caleb to remove legacy style text from r-l/fmt-rfcs
* [x] Jane to add note to policy document/meeting template that we do not record check-in/check-out items (excepting cases where we have consent that such an item should be included, translated into a backlog item, etc.)
* [x] Jane to add note to meeting template to incorporate section for reviewing action items, potentially backlog items too
* [x] Jane to add note to policy document covering process for adding items to the items to the backlog

## 2023-01-11

### Attendance

Caleb (secretary/lead), Michael, Jane (facilitator), Josh

### Agenda

* (Decide) process related questions (time-bound 10 minutes)
* when/how should we review action items during meetings
* when/how should we review the backlog
* how should things be added to the backlog
* should check in/out be captured in minutes, or should these be more private/internal to the team?
* (Explore, or hopefully Decide) let chains (until done)
* (Explore) review catalog of rustfmt version=Two differences and categorize - https://github.com/rust-lang/rustfmt/issues/5577 (if we have extra time)
* Meeting Check-out

### Minutes

#### Process related questions

##### should check in/out be captured in minutes, or should these be more private/internal to the team?
Jane: Feel strongly that those should be private/internal.
Josh: Seconded. Default just for us. Can persist specific items with consent.
Caleb: Agreed
Michael: Agreed
Jane: Should in particular capture action items.

*Action Item* Jane to add note about this to policy document that we don't record as part of minutes.

Jane: Some of the items will be translated into action items or backlog items, as well as any positive
commentary. Definitely don't capture personal/intrapersonal commentary, team members should also have the ability to request something not captured

Josh: Underscore the importance of consent being necessary for capturing any item from check-in/check-out

###### when/how should we review action items during meetings

Some shared sentiment that there is overlap with backlog+agenda prep

Josh: default off the backlog if empty, agenda items can be suggested/proposed during consent to agenda phase
Jane: Stresses importance of agenda preparation prior to meeting
Josh: agreed
Jane: Important that roles are defined outlining responsibilities of agenda planning
Caleb: Asks if we should we have a recurring meeting segment for reviewing prior action items
Jane: Agrees, dedicated section of the meeting to review prior action items, potenetially backlog items as well
Josh: Should have additional discussion to determine whether it needs to be fixed or can be more flexible/as-needed/per-action-item

*Action Item (maybe) - Jane to update team policy/charter with a note about incorporating this into the template

###### when/how should we review the backlog

Jane: Anyone can put anything on the backlog at any time
Josh: Worth capturing in team policy. Consent not needed to add to backlog, but consent needed to move from backlog to agenda (since agendas themselves require consent)

No pushback/team agreement

*Action Item* Jane to add note about this to policy document

#### let chains

Josh: We're nearly unified, shouldn't let perfection be the enemy of the good. Would be better to move forward with a proposal and not get lost in edge cases. Shift focus towards the next style edition with a focus on better "short" heuristics
Michael: Are we consolidating on option 5?
Michael: Recapping of prior discussion about concern raised from community around applicability, but acknowledging that the style-team explicitly prefers aesthetics in its order of precedence.

Proposal: We're going with option 5

Josh: New term "complex enough", if we were to go this route we'd effectively be handing that decision back to the rustfmt team, should not do this again because it's too ambiguous. Should not introduce a new term, should be fully enumerated
Josh: Option 6 flavor of option 5 which includes enumeration of other similar constructs to include in the rule to avoid similarly bad cases, e.g. https://github.com/rust-lang/fmt-rfcs/issues/169#issuecomment-1072872950
Michael: Hesitation around full enumeration of many different complex sub-expressions. Would rather keep it simple (just identifiers) or use a heuristic (i.e. short)
Jane: More complex expressions may have side-effects, aren't easy to intuit. Easy to gloss over, compared to identifiers.
Caleb: Hate to say it, but probably in our best interest to review where people would call out unexpected behavior. Understand concerns around enumeration, but worth going through and having a consistent reason why each expression should be wrapped or not
Josh: `a.b`? `foo()?`? Inclined to withdraw option 6, and work on better "short" heuristics separately.
Jane: Okay with allowing member access to be included in set permitted to be formatted across one line, happy to have the conversation around which, if any, additional ones warrant
Josh: Proposal - Option 5 yes/no, any objections?
Jane: No objections to option 5, but an objection to skipping over caleb's proposed review
Josh: Asked if Caleb has objection to option 5
Caleb: No objection to option 5, though feel better if we did a review of some expression types that could also be considered for inclusion in no-wrapping rules. If we end up with option 5 + few more then also fine with that.
Michael: No objections to either
Josh: Around member access, expects this to be an uncommon case. Possible, would eventually happen, but certainly less common trigger for "what the heck is rustfmt doing". Also agree with Jane's note that `foo()` doesn't fit easily into some mental models/intuitive tenant
Jane: Asks what kind of feedback can we get on proposal/direction before it gets finalized?
Caleb: Anticipates that when we open PR, that'll be opportunity for feedback.
Michael: Asks if we can we come up with a soft agreement, but acknowledge feedback is anticipated in that PR process? Would we actually change our decision based on feedback?
Jane: Communication should note our directionality, but not finality, and request feedback
Caleb: Any change stemming from feedback probably would be limited to more 'tweaks' types of changes as opposed to a complete pivot. Hopefully our direction is convincing enough that we won't need to shift. E.g. If we include idents + member access, maybe someone says "no member access", and we go back to option 5.
Josh: Realized in response to topic around whether feedback works, example from the compiler around let if chaining, reviewing existing cases in the compiler. Every case would be the same under the proposed rule (`if let .. && let ..`that would break) or would be better. First impression is that option 5 would have a solid, preferrable result on the compiler codebase
Jane: Should it be async or backlog item for next meeting
Josh: Proposal, let's try async and go through cases of existing usage within codebases
Jane: Sounds async
Caleb: Silently agrees
Josh: Probably a sync activity to resolve, but work can continue asynchronously

Jane: Should backup note taker be an official role (Michael assisting Caleb with notes especially when he's speaking)
Josh: who scribes the scribe :D "qui scribit scriba"

Potential Option 6: Option 5 but allow `ident`, `*ident`, `ident()` (only with empty parens), ...
(Josh: withdrawn)

Examples from rust-lang/rust:

// should break
        if let Interpolated(nt) = &self.kind && let NtPath(..) = **nt {

// should break
        if let Interpolated(nt) = &self.kind && let NtBlock(..) = **nt {

// breaking is correct here
        if qself.is_none()
            && let Some(partial_res) = self.resolver.get_partial_res(t.id)
            && let Some(Res::Def(DefKind::Trait | DefKind::TraitAlias, _)) = partial_res.full_res()

// should break
                        if let Some(guard) = &arm.guard && let ExprKind::Let(_, guard_expr, _) = &guard.kind {

// should break
            if let Some(span) = span && let Some(expr) = finder.expr {

// should break
    if let Some(l1) = borrow_place.as_local() && let Some(l2) = access_place.as_local() {

// should indent better (`&&` should not be aligned with `if`)
                if let ast::ExprKind::Lit(token_lit) = count.value.kind
                && let Ok(ast::LitKind::Int(count_val, _)) =
                    ast::LitKind::from_token_lit(token_lit)

// should break
            if self.tcx.sess.is_sanitizer_kcfi_enabled() && let Some(fn_abi) = fn_abi && is_indirect_call {

// Hey look, an example where specifically option 5 is a win!
    if diagnostics && let Some(f) = check_tied_features(sess, &featsmap) {

// Hmmm, should we allow `!ident` too?
    let operator = if !from_hir_call && let Some(p) = parent {

// Hmmm, should we allow `!ident` too?
    if !requested_fallback_locale && let Some(requested_locale) = requested_locale {

// should break
    if let Some(tt) = iter.next() && let TokenTree::Token(token, _) = tt {

// should break
        if gen_pos != GenericArgPosition::Type && let Some(b) = gen_args.bindings.first() {

// Another example where option 5 is a win.
        if incompat && let Some((descr, def_id, substs, non_exhaustive)) = non_exhaustive {

// bad indentation, `ty.kind` shouldn't be aligned with `&&`s
                                if let hir::TyKind::Path(hir::QPath::Resolved(None, ref path)) =
                                    ty.kind
                                    && let Res::Def(DefKind::TyParam, def_id) = path.res   
                                    && def_id == self.1.to_def_id()

// should break
        if let Some(hir_ty) = hir_ty && let hir::TyKind::BareFn(_) = hir_ty.kind {         

// `!ident`
            if !in_closure && let Some(output) = output {                                  

// option 5 is a win
        if in_closure && let Some(output) = output {

// should break
    if let hir::Node::Item(item) = node && let hir::ItemKind::Impl(ref impl_) = item.kind {

// should break
            if let Some(fn_decl) = node.fn_decl() && let Some(ty_id) = ty_id {

// insufficient indent
        if let Some(parent_node) = self.tcx.hir().opt_parent_id(self.path_segment.hir_id)          
        && let Some(parent_node) = self.tcx.hir().find(parent_node)
        && let hir::Node::Expr(expr) = parent_node {

// insufficient indent
        if let hir::QPath::Resolved(_, path) = qpath 
        && let Some(trait_path_segment) = path.segments.get(0) {

// insufficient indent
                if let Some(span) = self.gen_args.span_ext()
                && let Ok(snippet) = self.tcx.sess.source_map().span_to_snippet(span) {

// odd example
            if block.expr.is_none() && block.stmts.is_empty()
                && let Some(outer_span) = &mut outer_span
                && let Some(cond_span) = cond_span.find_ancestor_inside(*outer_span)

// `!ident`
                if !is_insufficiently_polymorphic && let Some(expr) = expression {

// should break
                if visitor.ret_exprs.len() > 0 && let Some(expr) = expression {

// should break
                        if def_self_ty.contains(*param_ty) && let ty::Param(_) = param_ty.kind() {

// should break, but also, these could be joined together if `!ident` is handled well
        if !explicit_return {
            if let ExprKind::Block(body, _) = return_expr.kind && let Some(last_expr) = body.expr {

// bad indentation, `) = error.code`  should not be at same level as `if` here
        if let traits::FulfillmentErrorCode::CodeSelectionError(
            traits::SelectionError::OutputTypeParameterMismatch(_, expected, _),
        ) = error.code
            && let ty::Closure(def_id, _) | ty::Generator(def_id, ..) = expected.skip_binder().self_ty().kind()
            && span.overlaps(self.tcx.def_span(*def_id))

// should break
        if let Mode::MethodCall = mode && let SelfSource::MethodCall(cal) = source {

// bad indent
        if let SelfSource::MethodCall(expr) = source
        && let mod_id = self.tcx.parent_module(expr.hir_id).to_def_id()
        && let Some((fields, substs)) =
            self.get_field_candidates_considering_privacy(span, actual, mod_id)

// should break
        if self.tcx.features().string_deref_patterns && let hir::ExprKind::Lit(Spanned { node: ast::LitKind::Str(..), .. }) = lt.kind {

// bad indent
        if let PatKind::Ref(inner, mutbl) = pat.kind
        && let PatKind::Binding(_, _, binding, ..) = inner.kind {

// bad indent, `.any` shouldn't match `&&`
        } else if self.autoderef(span, expected_ty)
            .any(|(ty, _)| matches!(ty.kind(), ty::Slice(..) | ty::Array(..)))
            && let (Some(span), true) = (ti.span, ti.origin_expr)
            && let Ok(snippet) = self.tcx.sess.source_map().span_to_snippet(span)

// this seems like correct breaking here
            if !fr.bound_region.is_named()
                && let Some((ty, _)) = find_anon_type(tcx, region, &fr.bound_region)

// odd formatting
                if let ObligationCauseCode::BindingObligation(_, span)
                | ObligationCauseCode::ExprBindingObligation(_, span, ..)
                = cause.code().peel_derives()
                    && let TypeError::RegionsPlaceholderMismatch = terr

// should break
                if let ty::Adt(expected, _) = expected.kind() && let Some(primitive) = found.primitive_symbol() {

// should break
                } else if let Some(primitive) = expected.primitive_symbol() && let ty::Adt(found, _) = found.kind() {

// should break
                } else if let ty::Adt(expected, _) = expected.kind() && let ty::Adt(found, _) = found.kind() {

// bad indent, `&&` here should be indented further
                    let sugg = if sm.is_multiline(blk.span)
                        && let Some(spacing) = sm.indentation_before(blk.span.shrink_to_lo())


// bad indent
            if let Some(recv) = extract_iterator_next_call(cx, arg)
            && let Ok(recv_snip) = cx.sess().source_map().span_to_snippet(recv.span)

// should break
                } else if !ty.span.from_expansion() && let Some(t) = is_ty_or_ty_ctxt(cx, &path) {

// should break
        if let Level::Expect(id) = &mut level && let LintExpectationId::Stable { .. } = id {

// should break
            if let Some(libname) = libname.strip_prefix("lib") && let Some(libname) = libname.strip_suffix(".a") {

// option 5 good
                if check_params && let Some(args) = path.segments.last().unwrap().args {

// should break
            if let Some(ref pat) = param.pat && let Some(name) = pat.simple_ident() {

#### Completed Action Items

## 2023-01-04

### Attendance

Caleb (secretary/lead), Michael, Jane (facilitator), Josh

### Agenda

* (Inform) quick status update on version=Two from rustfmt team perspective
* (Inform) quick status update on let-else statements from rustfmt team perspective
* (Explore) quick temperature check on let-chain statements; are we ready to decide?
* (Decide) Style Guide file artifacts in fmt-rfcs repo
* (Decide) Team policy and operations documents
* agenda / backlog / action items policy
* Meeting Check-out

### Minutes

#### rustfmt version=Two

Caleb: rustfmt team has completed enumeration of formatting differences, backlog item unblocked
process needed for reviewing list one by one
Josh: synchronous walk through, categorization for next style edition: definitely do, definitely don't, needs discussion
Team agreement to add review to next meeting time
Jane to coordinate with Josh to determine facilitation

#### let-else statements

Caleb provided update on prior action items that have been completed, and also shared that the rustfmt team has begun looking into implementation

#### let chains temperature check

https://github.com/rust-lang/fmt-rfcs/issues/169

Last meeting positions:
* Michael: 3, 4, 5
* Josh: 5, could be convinced otherwise
* Jane: 2, 4, 5
... though it seems like we need more time to discuss the options.

Jane: Are there any objections? Objections to 1
Josh: Objections to 1,3 and some degree 4.
Josh: Not a *strong* objection to 2, but example of ugly wrapping somewhat persuasive
Caleb: Leaning (heavily) towards option 5
Josh: potential missing scenario (caleb example), slightly more complex if f(). No magic heuristic perfect in all scenarios so we should strive to find one that typically works best
Jane: Interested in more clarification on community objection to option 5
Josh: Provided clarification of that objection...
Josh: Maybe consider changing rules to remove the "exception for let", but it's not obvious if we can. We do want to let things be on the same line. Let's evaluate wrapping rules for other things, is there a general rule we can write for forcing wrappings in other cases (more than just the presences of a let expr)
Jane: How do we consider/weigh tenant of style guide of simplicity vs. complexity-driven rule, is that a potentia concern? Importance of predictability of formatting
Josh: We have tenants enumerated in https://doc.rust-lang.org/nightly/style-guide/principles.html in roughly priority order. The "applicability" item (and in particular simplicity and ease of manual formatting) is historically a lower priority compared to readability and aesthetics.
Jane: we can acknowledge the applicability factor and agree, but will still lean towards other options given priority order of tenants

Scenario:

if f()
    && let ...

Jane: Summarzing, team leaning towards option 5 but still not finalized and more discussion needed.

#### Style Guide file artifacts in fmt-rfcs repo

Caleb: fmt-rfcs has historical version of style guide text, proposes we remove
Josh: Clarification on wehtehr loss of git history is a concern for Caleb
Jane: Not concerned with losing git level history for changes on those files. Actual information still exists (Issues and PRs in the fmt-rfcs repo)

Decision: proceed with removal, caleb will take action item

#### Team policy and operations documents

Jane has proposed docs in https://github.com/rust-lang/fmt-rfcs/pull/176

Jane: defer discussion of domains, whether where work would be done should be included
Josh: Add language that Style Team may invite individuals to join
Jane: Covered by previous section
Josh: Will suggest text to cover that scenario more explicitly
Josh: Can reach out ~~to T-Style or~~ via PM to individual member. We should do PM because some are uncomfortable asking in public, and we also wouldn't want to have to decline a request in public
Michael: Echo sentiment about PM to member, and member should always pass along any received request to rest of the team
Josh: Style Team members should discuss with full team before contacting any individual about joining
Jane: Will update doc with relevant Zulip links
Jane: Additional clarity about role of secretary to interpret policies in the event
Josh: uncomfortable with it being an *authoritative* interpretation, but comfortable with the secretary being responsible for facilitating interpretation and discussion
Caleb: agreed/reflects hesitation expressed in the PR comment. hopes that policies are never so ambiguous and subjective to the extent that a majority of the team cannot agree on an interpretation (but understand the need to identify a role to help facilitate the resolution of any divergent resolutions)
Jane: Will update PR to clarify that the secretary does not have authority but is in facilitation role

#### AOB

#### Completed Action Items

* [x] (let-else) Caleb to draft message of plan, share with team in private first
* [x] (let-else) Caleb to communicate plan to community on https://github.com/rust-lang/fmt-rfcs/pull/165 (and close given reloaction of style guide text to r-l/rust)
* [x] Jane to submit PR in r-l/fmt-rfcs documenting team policies and operating procedures
* [x] Jane to make a T-style calendar

## 2022-12-07

### Attendance

Michael (notes), Jane (facilitator), Josh (awesome)

### Agenda

* Check-in
* Constructing Agenda
* Review Action Items and Backlog
* (Explore) Policy Document
* (Explore) let-chains
* Check-out
* AOB

### Minutes

Check-in:
* Nothing of particular note, people are doing well.

Policy document:
* Josh calls out distinction between policy and charter. Charter is more about aims, domains, etc.
* Jane notes that we should be able to find both easily.
* Josh: Charter and policy should live as separate documents next to each other in the root of the repository.
* Team agrees on value in distinguishing both.

* Jane notes that the document should be somewhere to explore governance changes. For example, membership policy.
* Maybe we shouldn't start with T-style.
* Josh notes that it wouldn't be too hard to "test out" changes on this team, but might not be effectual.
* Jane notes that T-style may eventually want an operational and technical lead.
* May not be necessary given the nature of the team.
* Josh: Team lead should be primarily responsible for team meta.

Calendar:
* Michael: Should the T-style meetings live on the T-lang calendar? Easier to discover.
* Jane notes that it's hard to distinguish between unrelated teams' events when they're all on the same calendar.
* Josh suggests we announce the creation of T-style calendar during T-lang meeting.
* A bit of side-convo about how T-infra should manage calendars in general..

let-chains Made a very quick temp-checkl, team members are in favor of
* Michael: 3, 4, 5
* Josh: 5, could be convinced otherwise
* Jane: 2, 4, 5
... though it seems like we need more time to discuss the options.

Check-out:
* Jane: Glad that we're able to function when members are not present
* Michael noted time-crunch, asked for permission to be more annoying when people forget (i.e. unplanned absences)
* Josh wonders if we could make check-in or check-out opt-in, though we made no decision there.
* Team notes that there is value in having them, though.

### Completed

* [x] Josh to add tracking issue for style evolution in r-l/rust, and then merge associated RFC

## 2022-11-30

### Attendance

Caleb (notes), Jane, Josh

### Agenda

* (explore) Caleb to propose minutes doc suggestions (5 minute timebox)
* action items
* summary and/or transcripts
* (inform) review prior action items
* Caleb - let/else
* Jane - document team policy/operating procedures
* Josh - updates to Style Evolution RFC
* Josh - add Style Guide principle
* Caleb - updates on rustfmt vnext formatting differences
* https://github.com/rust-lang/rustfmt/issues/5577
* Review completed action items
* (?explore?) let-chains - https://github.com/rust-lang/fmt-rfcs/issues/169
* meeting checkout
* AOB

### Minutes

#### Minutes Suggestions

Caleb proposed some minor additions/modifications in how the meeting minutes document is structured

* Split action items into two sections, pending & completed, to differentiate outstanding items vs. items that the owner has reported as being completed
* During meetings the team will review the items reported as completed for confirmation and closure
* Note taker should not attempt to capture a full transcript in the minutes; they should try to balance capturing a succinct summary and individual comments/points

Unanimous agreement on the action item point, general agreement with goal of the capturing summary/discussion though with some follow up items and nuance.

Caleb: We could investigate meeting tools/platforms if there's a desire to fully capture a meeting, either with recordings or automated transcription captures
Jane: Meeting tools is a topic the Foundation is reviewing, action item to follow up
Josh: Full agreement on transcripts, but opposition to having full video recordings

Note - planning on having a consistent facilitator (Jane) and note taker (Caleb) for the next month or two. Afterwards will revisit and review.

#### Prior Action Items

Individual items enumerated in more detail within the agenda; all were covered in the meeting.

* Style Evolution RFC
* Josh: FCP done, needs merging but want tracking issues for implementation created first. Action items added
* Style principle
* Josh: added/done
* let-else decisions
* Caleb: still pending, didn't have time
* Document team policies and procedures
* Jane: forgot, but in progress
* rustfmt `version=Two` formatting differences
* quick share of the work being done to catalog the formatting differences of rustfmt between `version=One` and `version=Two` (a prior action/discussion item)
* Most of the `version=Two` formatting changes would be subject to inclusion in the vNext Edition of the Style Guide
* Item added to backlog to track the eventual work for the Style Team

#### let-chains

Not enough time to have detailed discussion of all potential options, so Josh suggested we enumerate key requirements/goals/considerations for how let-chains are formatted

* Ease of visual scanning (Josh) - prefer avoiding introduction of bindings on the far right
* Jane: agreed, easier to locate when on the left
* Visual consistency, simplicity, and symmetry (Jane)
* Intuitive (Jane)
* Josh: a "yes, and" - should be a general property/goal, especially for 2024 and future editions. Ideally formatting rules are intuitive enough for developers to write them correctly the first time, resulting in no action from the formatter
* Avoid/minimize arguably "bad" looking code (Caleb) - like hanging/floating elements that are prevented elsewhere, e.g. call/access chains
* Consistency with other Style Guide prescriptions (Caleb) - strive for consistency with rules for accompanying/similar constructs, e.g. binary expressions, unless there's strong reason not too
* Josh: agreed, though we may decide`let-else` is interesting enough to diverge

Josh: a possible 5th option that typically wraps but with a carve out for "simple" chains that can still be formatted across one line (e.g. a single identifer and let-else expression).

Agreement that this 5th option should be shared on the fmt-rfc thread so that the community can weigh in, action item to post.

## 2022-11-23

Cancelled with unanimous agreement due to holidays, lack of member availability, etc.
https://rust-lang.zulipchat.com/#narrow/stream/353175-t-style.2Fprivate/topic/meeting.202022-11-23

## 2022-11-16

(note from michael: Josh said that he wanted to talk about Explore/Inform/Decide and the value it brings to the meeting.)

### Attendance

Caleb (notes), Jane, Josh, Michael

### Agenda

- review action items from last meet (presumably an inform/explore)
- decide plan of action for let else + chains style determination
- if necessary discuss/explore style options
- discuss/explore meeting and topic structure (at least partially discussed asynchronously in https://rust-lang.zulipchat.com/#narrow/stream/353175-t-style.2Fprivate/topic/inform.2Fexplore.2Fdecide.20framing)
- meeting checkout
- AOB

### Minutes

#### Style Guide Snapshotting & Style Edition RFC

* Revisited discussion of archiving/snapshotting prior style guide editions
* Agreement that this is needed
* Agreement on need to document how rules for new syntax would cascade back to prior edition snapshots (when syntax is supported)
* Decision: Older edition snapshots will utilize formatting rules from first/oldest/subsequent edition that defines rules for the syntax
* Action Item: Josh to add back to RFC
* Style Evolution RFC
* Josh: two minor updates needed to RFC (action item)
* Discussion of the number of approvals/outstanding, agreement that a minimum of 3 approvals should be required with a 4 person team

### Plans for let - {else, chains}
https://rust-lang.zulipchat.com/#narrow/stream/353175-t-style.2Fprivate/topic/let.20else.20statements

* Josh: let else close, more edge cases to review.
* Jane: Recommend focusing on let else due to stabilization timelines vs. chains
* Michael: Confirmed let chains aren't due for stabilization in the near future
* Michael: Have some further thoughts on the edge cases and similarity to if-else. (https://rust-lang.zulipchat.com/#narrow/stream/353175-t-style.2Fprivate/topic/let.20else.20statements/near/308882213)

* Discussion summary
* Agreement to defer let-chains to future discussions
* General consensus that let-else inherently advertises control flow
* Josh: shared a guiding principle of the Style Guide came from the [Linux Kernel Style Guide](https://www.kernel.org/doc/html/v4.10/process/coding-style.html?highlight=hide#indentation) `Don’t put multiple statements on a single line unless you have something to hide`
* General consensus that the semicolon should, ideally, _not_ be load bearing. However, team agreement that it will be treated as load bearing in current style edition for consistency with other current style guide prescriptions
* **Decision** - let-else statement formatting rules will be option 1 (https://github.com/rust-lang/fmt-rfcs/pull/165#issuecomment-1060973041) with the slight addtion of the "if short enough to fit" sentiment clause utilized elsewhere in the current style guide (concrete proposal below)
* Action item for Caleb to communicate and take next steps
* Desire to revist this, and control flow prescriptions more generally, in future style editions

let Some(foo) = if cond { expr } else { stmt; };

let Some(foo) = expr else { return; };
                         // ^

// Today's formatting:
let foo = if cond { expr } else { return 42 };
let foo = if cond {
    expr
} else {
    return 42;
};

Concrete proposal (Josh):

- Format the `else` branch of `let`-`else` like the else block of an `if`-`else` expression, including whether it's on one line or not.
- Keep the "short" heuristics for the "else" block for now, such that if it's longer than the same configurable threshold, wrap it. Consider changing this in a style edition.
- Keep the "load-bearing semicolon" behavior for now, for consistency with if-else. Consider fixing this in a style edition.

Relevant links:

let-chains: https://github.com/rust-lang/fmt-rfcs/issues/169
let-else and let-chains impl: https://github.com/rust-lang/rustfmt/pull/5203
current control flow rules: https://github.com/rust-lang/fmt-rfcs/blob/master/guide/expressions.md#control-flow-expressions

### Principles, Policies, and Operating Procedures

* Discussion of an implicit style guide principle: plain text readability and avoiding reliance on syntax highlighting
* Action item for Josh to make explicit in the style guide enumeration of principles
* Discussion and desire to codify team modus operandi
* Action item for Jane to document team policies/operating procedures in r-l/fmt-rfcs

## 2022-11-09

### Attendance

Caleb, Jane, Josh, Michael (notes)

### Agenda

* Backlog
* Decide: Can we move forward with rfcbot on https://github.com/rust-lang/rfcs/pull/3338
* :heavy_check_mark:
* Inform: any other action items from last meeting
* :heavy_check_mark:
* Explore?: any items that can be removed from the backlog?
* :heavy_check_mark:
* Explore: Snapshotting procedure for the style guide
* :heavy_check_mark:
* Explore/decide: Formatting let-else
* :timer_clock: will continue decision in a follow-up meeting
* Explore: Proposed changes shared in the private stream
* aob (any other business)
* Check-out [5 mins]

### Minutes

#### Backlog

* Caleb: Figure out team operations -- we came to the decision that RFC process will be how we do things.
* Caleb: Should we codify when we use fmt-rfcs repo vs rust-lang repo?
* Josh:
* 1. Make a fresh repo and archive fmt-rfcs
* 2. Rename fmt-rfcs to style-team, move it to the rust-lang org, give T-style permissions to it, confirm that rfcbot remains set up for it :checkbox:
* Caleb: Need to find out whether infra stuff works on non-rust org repos...
* We should migrate everything to the rust-lang repo -- formatting stuff was originally under nursery.
* fmt-rfcs was basically what is now T-style
* Made a decision to do #2 above.

* Caleb: We can remove this one:
* Proposed additional item related to `version=Two`: should we require that changes between editions be controlled by configuration options, or can we also change things that *aren't*? Proposal: we can also change things that aren't, such as bugfixes.
* Whatever policy we want here should be in the RFC if we want it.

* No add'l action items for private stream, other folks should just go over the decisions that Josh has posted.

* Josh: Let-chains and let-else should have a concrete proposal for both of those.
* will remain in backlog until.

* Caleb left one comment on the style RFC, good to move ahead.
* Josh: Saw the suggestion. Tl;dr should update the text to account for the comment. Not blocking.
* Jane to do the rfcbot merge on the PR.

* Josh: `rfcbot poll` exists for quick polls of T-style opinion,
* Michael: e.g. useful for T-lang issues.

#### Style evolution

* Jane: Has been investigating versioning of style guide.
* Opened a [stream for discussion](https://rust-lang.zulipchat.com/#narrow/stream/346005-t-style/topic/Style.20guide.20snapshot.20mechanisms/near/308870033)
* Caleb: Only thing that needs to be done is have an unambiguous place to point for style for a specific version.
* Jane: Should we have a mechanism so that you don't need to calculate when a new feature was added for backwards-compatible style guidelines.
* Josh: If a given version of the style, go forward to *first* version that formats it. E.g. if let-chains style guidance isn't present in style edition 2015, will fall-forward to first edition that does describe it.
* Jane: Should note in the first edition that describes style guidance will explain that it applies to all previous versions lacking that feature.
* Caleb: Does un-specified style get formatted with the oldest version of a style guide, or latest?
* Seems like Jane/Michael/Josh agree on the oldest.
* Michael: Would break existing code pinned to an old style edition if we did the other way around.
* Jane: We should just enumerate all previous editions as policy, if we need a technical solution later then we can add it.
* Caleb: Agree, won't be hard to enumerate everything that is changing. Blog post that summarizes the changes should help.

#### Let-else

https://github.com/rust-dev-tools/fmt-rfcs/pull/165

* Jane linked to https://github.com/rust-dev-tools/fmt-rfcs/pull/165#issuecomment-1060973041
* Josh: Weakly opposed to option #1, easy to hide. Making it stand out more seems right.
* Jane: Not too easy to hide, because kw's are usually highlighted.
* Josh: One other item for consistency -- when we made decision about `if else`, `let _ = if cond {} else {}` if both branches are both exprs, but not if either blocks have any statements.
* Our actual way of defining it is if there's a semicolon.
* Josh: We should be consistent with `if else` formatting here...
* If we'd break `let x = if cond { ... } else { ... }` we should break `let Some(x) = expr else { ... }` as well, and vice versa
* Jane: Because of the divergence restriction, not sure if the same behavior as `if else` makes sense here?
* Josh: Is the fact that there's a refutable pattern on the LHS a sufficient signal?
* Jane: Either you look at the end of the line and see `return`, or beginning and see a refutable pattern.
* Josh: If, e.g. `if cond { .. } else { panic!() }` wouldn't wrap.

* Jane: The RFC already explains that we might fall back into options 3&4 because the line is too long.
* Josh: Correct, but it's not obligatory is the decision we're making.

* Jane: Feels strongly towards #1
* Michael: No strong, leaning towards #1
* Josh: #2
* Caleb: Doesn't care strongly, leaning towards #1

* Josh: Still needs to make up his mind. Option #1 is not fully defined behavior w.r.t. statements in blocks.
* Not exactly sure what the heuristic is there.

Follow-up will be scheduled.

#### Check-out

* Jane: Thought meeting went well
* Jane: Backlog was confusing, not exactly sure what the goal was for some of the items.
* Jane: We need more practice on Explore/Inform/Decide.

* Josh: Feeling great about making decisions in these meetings and making forward progress on the other items.
* Josh: Excited for actually doing the work!

* Michael: Feel pretty good about how meetings are running.

* Caleb: Echo novelty of system, biased because we're moving forward and taking pressure off rustfmt!
* Glad meetings are necessary and end on time!! :turtle:

## 2022-11-02

### Attendance

Michael (Minutes taker), Josh, Jane, Caleb (facilitator)

### Agenda

- Explore: https://github.com/rust-lang/rfcs/pull/3338
- Inform: any other action items from last meeting
- rustfmt team is working on enumerating formatting differences with version=Two
- :clock1:
- prefer style_edition as name for new option specifying style guide version
- :heavy_check_mark:
- Explore: Snapshotting procedure for the style guide?
- aob (any other business)

### Minutes

- Making style team decisions should require 3 people (while we currently have 4), as long as rfcbot doesn't enforce this. (Josh thinks rfcbot *might* enforce that.)

RFC:
- There's been some dialogue in the thread
- Caleb: rustfmt is the implementation of the style guide
- Caleb: Difficult to distinguish rustfmt's responsibilities vs T-style's.
- RFC is not just covering style evolution from the perspective of the style guide, necessarily needs to prescribe how rustfmt implements that.
- Should it be a FCP with both T-style and T-rustfmt?
- Caleb: People are asking questions about rustfmt's stability responsibility, not necessarily the process of evolving style.
- Caleb: rustfmt has a stability guarantee written in an RFC long ago: https://rust-lang.github.io/rfcs/2437-rustfmt-stability.html
- Q: whose responsibility?
- Josh: rustfmt's scope, due to interest in e.g. librarification.
- Josh: Should Caleb leave a comment distinguishing T-style's responsibilities vs T-rustfmt's.
- Maybe mentioning the RFC itself.
- Caleb: Jane brought up new syntax questions, has been a problem on the rustfmt side. Independent of evolution process.
- Doing nothing is an explicit guarantee?
- Josh: Eric's question about what the style version allowed to change? What might change across editions seems like a T-style question.
- Josh: Yes technically we could, but what should we *expect*?
- Caleb -- example of different changes that do or do not need editions:
- this would require an edition change - https://github.com/rust-dev-tools/fmt-rfcs/pull/147
- type of change that would not require a change/doesn't necessitate breaking formatting changes - https://github.com/rust-dev-tools/fmt-rfcs/pull/159
- Michael: When do we clarify that rustfmt explicit does nothing?
- Jane: Possibly when we want to change it moving forward.

* Jane: Do we have a plan for new syntax?
* Caleb: We've (rustfmt) been out of the loop for language changes that are being stabilized. Rustfmt didn't see new language constructs. Because of that, surprise, there's new syntax we must deal with.
* Caleb: We don't have process about this currently. Definitely something that needs to change -- there's wiggle room for handling new syntax though.
* Caleb: There's no wiggle room on nightly -- that's why the status quo is do nothing until we know what it is that we want to do.
* Caleb: Moving forward, for new syntax, now that we have T-style, we could afford some syntax churn on nightly.

* Caleb: For example, if you're using edition2015, it can parse let-else but if we're running with style-edition 2015, let-else has no rules.
* Caleb: Rustfmt could do nothing, or it could fall-forward to newer formatting rules.
* Jane: This is relevant to her concerns about snapshotting the guide every time we fork a new style edition. Can we find a way to find the style guide and rustfmt be modeled similarly to how the compiler handles editions?
* Josh: We should format let-else in all editions it's valid in.
* Caleb: Rustfmt needs to know how to apply all the rules anyways. That's not an implementation concern, it's a documentation concern. How easily can someone look at the style guide and find out what rules apply?
* Configuration options exist so people can opt-out of default style choices -- conversely, style guide should focus on how we want code to be formatted.
* Josh: Should we block feature stabilization on having a formatting construct?
* For previous features (e.g. let-else) we didn't, because T-style did not exist.
* But moving forward, Josh doesn't see a problem with changing T-lang policy for stabilization to depend on the formatting rules being set.
* Idea: We could run the entire test suite through rustfmt and fail if we find something that isn't formattable (upon stabilization).
* Defer

* Caleb needs a few days to review the style evolution RFC!

* Jane: Should we document the goal of every agenda item (informing, explore, decision making, etc).

* Josh: `style_edition` should supercede `version = "Two"`?
* Caleb: Yes. rustfmt typically soft-deprecates even unstable options, so we'll soft-deprecate version and map it to a style edition.

Snapshotting versions:
* Caleb: Regarding snapshotting -- do we have multiple copies of style guide, or some immutable style guide and rules that are applied on top?
* Josh: Jane's suggestion makes it less concrete *how* we do the snapshotting, that leaves us options of implementation.
* Jane would like to see if we could have a base + diffs from a technical standpoint. Seems like it needs tooling or a lot of manual work.
* May not matter, differences between editions seems small.
* Josh: Anticipates changes to not be small that this may matter. (e.g. changes where lines wrap, examples need to be changed to match new style.)
* Idea from Jane: Rustfmt should be applied to unformatted examples to reflect per-edition changes :brain:
* :thumbsup: from Caleb, style guide has had discrepancies in practice. Snippets don't always demonstrate what the text is reflecting.
* Josh: We don't need to rustfmt the examples, but instead rustfmt "check" the style guide (so it's like a test).
* Jane: Will do proposal shaping on how to handle multiple versions of the style guide, what the constraints/goals of that implementation are (what properties we want to have, how we get to them.).

Let-else and let-chains
* Caleb: Maybe asynchronously we should form opinions about let-else and let-chains.
* Jane: Should we make decision inline in RFC?
* Caleb: Yes, for the sake of transparency. Then someone can PR the changes back to the rust repo.

## 2022-10-26

### Attendance

Michael, Josh, Jane (minutes taker), Caleb (facilitator)

### Agenda

- Figure out team operations
- Make decisions on some tactical items
- [add let else statements](https://github.com/rust-dev-tools/fmt-rfcs/pull/165)
- [wrapping rules for let-chains](https://github.com/rust-dev-tools/fmt-rfcs/issues/169)
- Long term goals
- formatting evolution

### Minutes

- Caleb: We've gotten by with minor typo-fixes to the style guide, but have treated it as a non-starter to make any real semantic changes.
- let else / let-chains don't have enough consensus and no call-maker
- let-chains have two sensible options and we need to pick one
- do we treat them like we do other expressions in an && or || (can be same line if simple/short)
- do we always linebreak
- let-else has many individual opinions that haven't been collated
- we can talk about team operations and formatting evolution now and visit those specific decisions later
- previous team had fmt-rfcs lightweight process
- made sense for the style-guide, many bitesized proposals/questions
- expecting some larger decisions now and many very small decisions
- for small ones fmt-rfcs feels too heavyweight
- recommend defaulting to just writing PRs to the style guide and FCPing those
- community is largely unaware of the style guide and the fmt-rfcs processes
- style guide now lives in rust-lang/rust so hopefully this will contribute more visibility
- As of https://github.com/rust-lang/rust/pull/102239 and https://github.com/rust-lang/rfcs/pull/3320
- if we add formatting edition we need a process for snapshotting the style-guide that defines the previous edition
- lets schedule meetings during previous meetings until we have a rhythm
- long term we should schedule a recurring meeting to avoid having to spend time on scheduling each time
- Eventually if we have much of the policy work done and move to more one-off questions we might scale back
- evolutions we want to make
- defaults are supposed to precisely follow the style guide
- rfc acknowledges challenges with adjusting default format over time
- was originally intended to be distributed as a crate to allow 2.0 releases
- couldn't happen due to using internal apis from rustc
- publishing was a maint nightmare as well as compat hazard for users
- haven't published for 2 years now, distribute thru rustup
- has to follow existing versioning expectations and stability policy
- cant change style-guide without breaking defaults
- Have a rustfmt configuration option to opt into new formatting rather than compatibility
- there are some obvious known issues we're stuck with atm
- what options does the "Two" cfg change? Is it all stuff controlled by other config options, or does it change miscellaneous other things too that don't have their own options?
- Josh's proposal for evolving the style: https://hackmd.io/OL2dZW1lQ3mHMhwcSAYfLg
- Bullets at the end are Josh's bikeshed proposal for specific changes
- Paragraphs at the start are the proposed evolution mechanism
- **action item**: review the proposal
- debatable whether we want a separate toggle
- convincing arg: don't want to migrate everything at once during a migration, might want to split them across commits
- separation of semantic and syntax changes
- We can default to using the edition config option and then add an override for using older edition formats (Jane reaction: :heart:)
- ties back into snapshot concern
- needs to be URI accessible so rustfmt can link to the style guide versions
- we can copy and fork for style guide editions
- issues come up when we want to handle new constructs that are added to all editions
- (Jane Idea) some sort of base style guide + snapshot deltas?
- should hopefully not need to adjust existing decisions very often, small deltas
- Issue: things that never got codified before
- These should still be treated as changes that have to come at an edition
- we can get away with being a little disruptive for new constructs
- **action item** Josh will setup the format evolution RFC
- what should the option be?
- **action item** Caleb will review existing options to ensure consistency (tentatively `formatting-edition`)
- we should split the mechanism from the specifics into two RFCs
- I'd suggest going thru the various options and see what defaults each of us would pick, independent of backwards compat
- given potential for controversy, should we discuss this internally before publicly?
- Better to talk with team members before users / rest of project
- meet weekly same time for now #urgent

----

Template for each meeting:

## Next Meeting Date

### Attendance

### Agenda

* Agenda consent + Check-in
* Review prior action items
* (inform) bullet point list of proposed agenda items (labeled either inform, explore, or decide)
* Meeting Check-out

### Minutes

#### Review Prior Action Items

###### Completed