Nushell core team meeting 2025-04-02

Attendees

  • Darren
  • Jack
  • Rose
  • Andy
  • Douglas
  • LoicRiegel
  • Stefan

Agenda

  • vibe check: pipeline assignment operator
  • Naming of datetime natural-language-conversion commands (see this Discord thread and subsequent comments)
    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: 
      ​​​​"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.
  • command internal column selection 
    ​​​​{
​​​​  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

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

Select a repo