/datum/x
var/L = list(1) + list(2)
This allows 2 things primarily:
1. Easier interactions with macros. Currently if we want to have many places at once share a common list (in SS13's case, we want to have all heads of staff carry some job traits) without a common subtype or extra complexity, we have to do something like:
#define COMMON_TRAITS TRAIT_1, TRAIT_2, TRAIT_3,
/datum/x
var/list/L = list(
COMMON_TRAITS,
/* more */,
)
This is ugly and fails the principle of least astonishment (it looks like one item, but it's actually several).
I would like to be able to have COMMON_TRAITS be a normal list that I add.
2. It makes interactions with parent_type and :: possible with lists.
Imagine the same scenario as before, but with a common subtype. I want to add more stuff to the list. I would like to do:
/datum/x
var/list/L = parent_type::L + list(
MORE_TRAIT,
)
But I cannot, and instead have to settle for extra code separated from the typepath. The runtime implications are the same (ignoring optimizations the DM compiler could make to precompiling the list), but are extra clunky.
This bothering me too, especially lack of init() for lists, so currently i was thinking about any nice ways to store lists in formatted text variable, so i can do real list initialization in New() or by demand (this can also save some memory). Like params (param2list/list2params) or json (json_decode/json_encode) or something else, maybe with help of some formatting macros. But this method has own problems, for start - preprocessor can't parse [] for object text variables, https://www.byond.com/forum/post/2904067
But it would be nice to have some build-in way to work with lists before initialization, even if it's not real lists.