# Nushell core team meeting 2025-04-02
## Attendees
- Darren
- Jack
- Rose
- Andy
- Douglas
- LoicRiegel
- Stefan

## Agenda
- [x] vibe check: pipeline assignment operator
- [x] Naming of `datetime` natural-language-conversion commands (see [this Discord thread and subsequent comments](https://discord.com/channels/601130461678272522/1348791953784836147/1353418672533798982))
We currently have:
* `date humanize`: Formatting a datetime in a natural-language form. E.g.:

     2025-04-02T16:00:00-04:00 | date humanize
     # => in 3 days

* `into datetime`, which today *automatically* attempts to parse/interpret natural-language into a `datetime`, but will simply return `date now` if it fails. E.g. [#14790](https://github.com/nushell/nushell/issues/14790):

    "next Monday" | into datetime
    # => Sun, 30 Mar 2025 09:44:05 -0400 (now)

The proposal is to make the natural-language-parsing *opt-in* by either requiring a flag on `into datetime` or moving it to a new command altogether. The question is what to name the flag/command and whether or not to rename `date humanize` to match.
- [x] command internal column selection
- prompted by [#15455](https://github.com/nushell/nushell/pull/15455)

    {
      foo: (date now | into int), 
      bar: (date now | into string), 
      baz: ignore
    } | into datetime foo bar

- type-inference conflict with record -> type conversions

      record -> record
      record -> datetime

following commands receive the wrong type (or an underspecified type if we are smarter in the inference)
- If we remove it
- `update $col {}` can only deal with one column per invocation
- `update cells --columns [...$cols] {}` pretty wordy

## Topics for next meeting
- [ ] how do we feel about renaming `$it` to `$in` for `where` condition

## Discussed Topics

### Pipeline assignment operator
- https://github.com/nushell/nushell/issues/14870
- potential special case in impl

  $foo |= $in | bla

Is the variable `$in` populated corrrectly in mutable assignment operators?

### human language datetime parsing/outputting

- flag vs separate commands
- flag lower fragmentation
- separate command keeps the complexity out of the necessary core command for type conversions
- as a separate parsing command for spoken language: `date from-human` seems acceptable
- date parse may imply stricter parsing (following the rfcs) which we would keep on `into datetime`
- `date humanize` seems acceptable

### input/output type challenge - case `into datetime` with record input

- type cheapout: resort to any, RTTC only
- type system enhancement: allow to specify `union[record, datetime]` which would static check with both `\ expect-record` and `\ expect-datetime` but then collapse the wave function at run time/
- dropping the cell path shorthand broadcast: would loose QoL vs `update cells`
- all `into` variants have, especially useful during data ingestion

Way forward: any for now, better type system when we get to

record -> any

According to Rose we could have the specific ones as documentations after the any case.

Alternate route:
separate commands for record to scalar conversions like `path join` / `url join`