Open fingolfin opened 5 years ago
I think my preference would be a mixture of (1) and (2), in many cases I think PLAIN_LIST
is an optimisation. If we could write a C++ template list wrapper, it would be easy to optimise many algorithms for plists vs normal lists.
Related issue: #3155
Also somewhat related: #815
This is about the definition of immutability. At the moment immutable objects are explicitly allowed to change representation, add stored attributes, etc. as long as they do not cease to be equal to their old values. So at the moment, kernel code that assumes that this will not happen is actually buggy.
We could change our mind on this and (for instance) forbid immutable objects from changing representation in-place. That would forbid switching permutations from perm2 to perm4 format, for instance. We could just impose that rule on lists.
Alternatively, we could just try to reduce the number occasions on which these changes happen, but then the kernel code is still buggy, but harder to detect.
My point being that if we want to change something in this area we should be clear what we are doing and whether it is guidance or policy.
Motivation: all kinds of problems can crop up if e.g. an immutable string object is silently converted to a plain list. It also means that all places in the kernel that currently expose immutable string objects to the user are in danger, as users could cause those strings to be turned into plists (e.g. as in issue #815), which then later leads to crashes when some other kernel code accesses those string, expecting them to be still string objects.
Therefore, I think
PLAIN_LIST
should not accep immutable objects, but rather trigger an error for them. Of course it's not as simple as that: we'd also have to audit all calls toPLAIN_LIST
to ensure they only are performed for immutable inputs. Some approaches that can be used to this end:PLAIN_LIST
to switch from plist APIs like ELM_PLIST to ELM_LIST etc.;PLAIN_LIST
, we could instead call a function which creates a new plist with the content of the old list (at least for immutable inputs)All of this could of course be applied to other in-place conversion functions; to this end, it'd be interesting to collect an overview of them (in particular, I am not sure if any exist that do something to string objects?).