Gotcha for &ordered attribute on record fields

[awelzel]

Talking with @bbannier a bit around, copy(), attributes, and gotchas. The following is a valid script today:

type R: record {
        s: set[string] &ordered &default=set("1", "2", "3", "4", "5");
};

event zeek_init() {
        print R();
}

And it probably doesn't do what was intended:

$ zeek x.zeek
[s={
4,
3,
1,
2,
5
}]

Putting &ordered as part of (or just behind) &default does likely what was intended:

type R: record {
        s: set[string] &default=set("1", "2", "3", "4", "5") &ordered;
};

We may consider this just a variation of the existing gotchas around attributes and how they bind to values rather than vars/fields. And possibly default initialization for containers isn't prevalent enough (though minimally Files::Info has analyzers with &default=string_set() - possibly historically), but maybe warning/erring on such constructs would not a bad idea.

[bbannier]

I think it is currently impossible to use parentheses to group such attributes to make intended semantics clearer. Maybe that would be a first step towards making this easier to control.

[awelzel]

I've moved this to zeek-docs, as documenting might be the most sensible action for now.