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
  • prompted by #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