Document idiom for mutable default args -- use `null` and initialize them in body about oil

[bar-g]

Minimal example to test with default value, and then without.)

setvar mydict = {}

echo passed variable before:
= mydict
echo

proc a(; input={} ) {
#func a( input={} ) {
  echo "input:"
  = input
  echo
  
  setvar input['a_added'] = 'something'
}

a (mydict)
#var dump
#setvar dump = a(mydict)

#echo retured:
#= dump
#echo

echo passed variable after:
= mydict
echo

[bar-g]

Thanks for posting the 0.19.0 blog article it provided some good context around the "Default values can't be mutable" part here. (I will move the second part to a different issue.)

https://www.oilshell.org/blog/2024/01/release-0.19.0.html#background

We disallow mutable default args, a well-known wart in Python

Uh, so I didn't know that one, as I don't know writing Python. I didn't know that official gotcha https://docs.python-guide.org/writing/gotchas/

The consequence from that python behavior though, which is from evaluating defaults into a var on func definition and then keep references that variable, looks awful to me: What are those (cosmetic) function signature defaults good for, when in practice, they can only be set to None and get used as a mere switch for a re-computation and assignment within the function, which is thus always required, anyway.

YSH's current corresponding strict disallow rule, is understandable with that background, but that ugly python background rather calls for a proper fix in YSH. (The old python way of using pseudo None defaults will still work.)

It seems to me python is mixing things that need to be separated.

What Python implicitly does for each default value seems to be creating a mutable global (The gotcha doc mentions it can be “exploited” (excusingly: used as intended) to maintain state between calls of a function.)

What do you think about these options:

• calculating the default on call time (as ruby)
• copying the value into a new proc/func local var
• allowing to specify an =(expression)
• specifying a place as default in the proc/func definition could still allow using a centrally mutable global default

[bar-g]

Maybe the gotcha that exists in python with mutable defaults can also be solved nicely by explicit syntax that distinguishes between pointing to some variable default and assigning an explicit on one at each call time (state=->dict, init={}).

Also see example in "=-> as explicit "pointer assignment" for mutables?" #1796

[andychu]

So the Python-like workaround is

func f(arg=[]) {   # BAD
 echo
}

func f(arg=null) {
  setvar arg = arg or []
}

We probably should document that somewhere, not sure where ... but Python programmers may know it

maybe in the FAQ

[bar-g]

Of course document workarounds in the error message that forbids mutables. :-)

[bar-g]

AFAIU the python workaround could continue to work, even if ysh explicitly distiguishes between assigning defaults by value withparam=default and by reference pointers withparam=->default explicitly.

[bar-g]

Ok, mentioning in the strict error message the workaround to set a default =null + setvar param = param or [] can work for now, but it's still a wart, and seems fixable as of the overview in: #1793 (comment)

[bar-g]

Of course documenting would depend on the solution found.

• #1866

Which could make the problem smaller, or even disappear when removing the [EDIT: in-]consistent semantics for different variable types (i.e. require '->' for mutables, and using value.place for them, to allow to re-bind for all aliasing semantics by default.)