# Nushell core team meeting 2025-02-05
## Attendees
- Andy
- Piepmatz
- Rose
- Douglas
- Michael
- Stefan
- Jack
- Yash

## Agenda
- [x] Release status? Do we need a patch?
- [x] [15001](https://github.com/nushell/nushell/pull/15001) Provide input and direction for `let x += 1`
- [x] Evaluate std-rfc process

Next time:
- [ ] Behavior of background jobs on shell exit

## Discussed Topics

### Release 0.102.0 status report

- Thanks Yash for doing a flawless first release!
- Only minor new issue reported: some bad span in config error reporting
- potentially related to the breaking change to filesize display config
- let's maybe check with a clean 0.101.0 config going into 0.102.0
- let's go ahead merge PRs if nothing else pops up,

### [15001](https://github.com/nushell/nushell/pull/15001)

- combining operator assignment with the new name binding of `mut` and `let` (as a short hand of a shadowing )
- cursed semantics with loops (easy to confuse with a deliberate mutable)

      let x = 0
      for i in 0..10 { let x = $x + 1; print $x }
      #> 1
      #> 1
      #> 1
      #> 1
      #> 1
      #> 1
      #> 1
      #> 1
      #> 1
      #> 1
      #> 1
      for i in 0..10 { let x = $x + 1; print $x }
      mut y = 0
      for i in 0..10 { mut y = $y + 1; print $y }
      #> 1
      #> 1
      #> 1
      #> 1
      #> 1
      #> 1
      #> 1
      #> 1
      #> 1
      #> 1
      #> 1

- instead allow `mut` in function argument bindings? (`def greeting [mut hello: int]`)
#### side observation in the PR: bad verification of variable names
- look into fuzzing tests to see where parser might be too lenient?
- let's tackle it in the old parser, but also get tests going to ensure sound behavior when transitioning to new-nu-parser

### std-rfc strategy

- `nupm` isn't there yet that shipping that `nu_scripts/std-rfc` directory is so low effort that folks dogfood it sufficiently that we move things properly into the right priority
- Rose: perverse incentive that its harder to get something into std or even std-rfc compared to a new rust builtin.
- potential solution: `@unstable` attribute to warn but land easily. if we could feature gate that for the users that dare to use unstable stuff.
- how to set that up so it is under positive user control.
- does `$env.config.unstable_modules` qualify?
- launching `nu` with specific flags/env vars (PITA?)
- continue in drawing board to have an unstable mechanism
- simpler move have a module in the `nushell/nushell` tree for now
- regularly move things in their right place, accept/ditch