If Kevan doesn’t enact this, I don’t think the last part will work since it can’t be carried out immediately by any other admin who enacts it. We’d need a rule that can be repealed after being performed once.

My thinking was that the order of a collection shouldn’t matter. The alphabetical nature is a way to obscure when stuff is added to it. This might be good enough though.

I’m not convinced that we always mean “can contain repeated elements” when we say that something is a list. It’s the hardest one to search the archives for, but a mechanic that acted on a simple “list of players” would be very surprising if implicitly interpreted to allow (via some carelessly worded rule that unintentionally added a player twice) duplicate entries.

I’m leaning towards Clucky’s interpretation on Discord that the “whenever that Agent is in the same Location as other Agents, add that Agent’s name and the Location to the Discovered” is explicit enough about creating multiple copies, though. Given that this reading potentially reveals private information not yet revealed, I’ll let this run to 24 hours to see if there are any other views.

(And no, the “At their earliest convenience” clause doesn’t work, but I’ll read the room on it.)

Leaving towards the view that this is not a behaviour that can or should be defaulted.

Yeah, I’m of a similar view. How a list works is decided as part of defining how you add items to the list, and most of the time we don’t actually care about the order. Leaving it able to be shuffled about can help with readability.

@Kevan: Note that you can’t reveal the information under the gamestate-corrections rule that we would normally use to fix incorrectly performed actions.

You would have to use the “revert incorrectly done steps of an atomic action and redo them” rule instead – but that would mean that we’ve been in Planning the Break-In all this time, not Setting Patrols, and that would probably have big ramifications for the gamestate. We might need an uphold CFJ.

(We could also get rid of the rule against disclosing secret information, leaving it up to Emperor discretion like we did in previous dynasties.)

I’ve now completed the action by reverting incorrectly done steps; players who discovered anybody have been told how many times and where they discovered them.

I don’t see that this has had any ramifactions.

> but a mechanic that acted on a simple “list of players” would be very surprising if implicitly interpreted to allow (via some carelessly worded rule that unintentionally added a player twice) duplicate entries.

To me, this is part of the concern. One person might assume that a list of players is enough to implicitly ensure names can’t be included twice. Another person might assume that as long as it gets added again, it technically gets included twice

Ideally people should define it as part of adding the rule but when in doubt, I’d like some sort of default behavior defined

It’s clearly not intuitive that any definition of a list should specify ordering and capability for duplicate entries, because that wasn’t written into it here and nobody noticed; and it’s clearly not intuitive what the default behaviour should be if not specified, because people have been debating it.

I don’t disagree that it would be ideal if these things were specified every time, but I can virtually guarantee you they will be overlooked or forgotten again in the future. We should write the rules to be robust and fault-tolerant, instead of assuming future ruleset changes will be drafted perfectly.

I guess the situation here is:
- if we don’t do something like this, people will use the word “list” with different meanings and the ruleset won’t support one over the others, potentially making it unclear what the list is
- if we do do something like this, people will use the word “list” with different meanings even though the ruleset does support one over the others, meaning that sometimes the ruleset will interpret a rule in a way that was clearly different from what was intended

These both seem like undesirable situations and I have no idea how to resolve the issue.

I’m confused as to why this is controversial at all. We have a fairly robust set of definitions in “Numbers and Variables” for all sorts of gamestate types, many of which have evolved over the years to cover this exact sort of misunderstanding.

Why is defining the default properties for a list value any different than defining the default properties of a numeric value?

Things like “spending means reducing by a positive amount of your own resource” and “numbers are usually positive integers” are default rulings that people generally wouldn’t be surprised by. In any Nomic or game it’d be unlikely that players could “spend” one another’s gold, without a rule explicitly spelling that out.

Whether or not lists should include duplicates is less obvious. I think it’s fairer to take ambiguous cases to a discussion within the dynasty that created them: of what people thought the rules meant, and whether any of the clauses implied or disproved duplication.

in favor of my Proposal to make this explicit for the Discovered list.