Adding a &create_default attribute

[vpax]

The semantics of &default are that the given value (expression) is returned if the corresponding field or table entry is missing. Often it would be handy for that value to then also be assigned to the field or inserted into the table. This especially comes up when the default value is a container. For example,

type r: record {
	a: count;
};

global x: table[count] of r &default=r($a=0);

x[5]$a = 7;

print x;

prints { } (an empty table), not a table with [5] = [a=7] like you might expect.

Proposal: add &create_default=expr to mean that missing entries should be initialized to the given expression upon first access.

[awelzel]

As this is in discussions: Some thoughts and roaming:

• Changing the default behavior of &default would be too intrusive I take it? That would be Python's collections.defaultdict behavior, but can see how that may surprisingly add state to a table.

• &default today supports functions for dynamic creation of default values (that doesn't seem to be documented though ...). If we would add the involved table as optional argument, one could do the assignment during execution of the default function. Mostly inspired by Ruby's Hash.new / default_proc approach, https://docs.ruby-lang.org/en/master/Hash.html#class-Hash-label-Default+Proc. The following actually works today, the extension would be to add the table to the function. Drawback might be that it's a bit more work/noise to use a function compared to a simple &create_default=expr approach.

type Foo: record {
        x: count &default=0;
};

global foo: table[count] of Foo &redef;
redef foo &default=function(i: count): Foo {
  # instead of the redef trick, foo could be the second parameter to `function(i: count, foo: table[count] of Foo)`
  local r = Foo($x=i);
  foo[i] = r;
  return r;
};

print(foo[0]$x);
print(foo[1]$x);

print(foo);

$ zeek language/table-default-record-insert.zeek
0
1
{
[1] = [x=1],
[0] = [x=0]
}

Proposal: add &create_default=expr to mean that missing entries should be initialized to the given expression upon first access.

Could also see a marker attribute &assign_default or &default_assign on tables/records. This would allow to keep &default as the only way to specify an expression/function with the default, while assigning on lookup miss is a separate attribute. (Also looks easier from the existing code perspective).

[vpax]

• Changing the default behavior of &default would be too intrusive I take it?

Unfortunately yeah I think it would be. There could be situations where it leads to a lot of unexpected increased state.

• If we would add the involved table as optional argument, one could do the assignment during execution of the default function

That would though be quite a bit more clunky though than just dealing with it via an attribute ... and less readable.

Could also see a marker attribute &assign_default or &default_assign on tables/records

Yeah I could see that going either way. I like the &create_default approach because it's more concise, but it's somewhat a matter of taste.

Also looks easier from the existing code perspective

Actually I think they're pretty much equivalent. The parser can turn &create_default into the internal equivalent of &default + &assign_default, so just one or two more lines of code, if I'm picturing it correctly.

[ckreibich]

For record fields &default already implies assignment (or at least identical-looking behavior), no?

type Foo: record {
        tab: table[string] of string &default=table(["foo"] = "bar");
};

event zeek_init()
        {
        local f: Foo;
        print f; # shows foo=bar
        f$tab["blum"] = "frub";
        print f; # shows foo->bar and blum->frub
        }

[vpax]

Yeah, the key difference is that for tables &default can be useful for either (1) a catch-all default for things the table has, especially handy for keeping it small, (2) a natural starting point for any new element. These two are in tension, which is why I think a new attribute makes sense, since sometimes you want one and other times you want another . The state-holding implications are different than for records because records are bounded in size (and small) and tables aren't.

[ckreibich]

Yeah, that all makes sense to me. I just read over the &default docs and they're missing lots of this detail, so closing that gap will need to be part of this work.

[awelzel]

Implemented in #3179