Also: While the warning mentioned that loaOf is deprecated, it only triggered when a list was assigned to it. So naturally the next step is to only remove support for assigning lists, and add a warning for loaOf being used itself. So something like this:

{
  loaOf = lib.warn "loaOf is deprecated blabla..." attrsOf;
}

Uhm, it looks like changing options to attrsOf broke the manual, for some reason.

Option references in docbook are:

• opt-foo._.bar when foo is listOf (submodule ..)
• opt-foo._name_.bar for attrsOf (submodule ..)
• opt-foo._name__.bar for loaOf (submodule ..)

This is why the manual fails, the references need to be changed from _name__ to _name_

Thank you, done. I don't know how the Nixos options integration in docbook happen, so is there a file that needs to be updated for the removal? I couldn't find any more references to loaOf.

No idea either, haven't looked into it

We replace the ? in ids for _ here:

The id just comes from the option name itself IIRC.

@jtojnar, sorry but I understand very little of what's going on in that file. I still don't see anything related to loaOf in it, what should be changed?

We can drop the outermost replace if no other type adds ? to the generated option name lika loaOf did in getSubOptions.

Ok, I think I get it. It's because loaOf uses <name?> as a placeholder.
Yes, it seems no other type does this and the manual builds, so it should be safe to remove.

Thank you all!

Absolutely, and I return the thanks ten fold ✨