On 14.06.20 20:25, Paul Backus wrote:
On Sunday, 14 June 2020 at 16:26:17 UTC, Avrina wrote:
The situation also applies to the only tuple implementation in D. If
you are proposing a new type with emphasis on reducing the footprint
of the tuple then I don't see a problem with that. Changing the
existing tuple implementation would be problematic.
Presumably any such change would be made backwards-compatible. So
Tuple.opIndex and Tuple.expand would still return elements in the order
specified by the user, even if that order is different from the internal
storage order.
Indeed, that's why I noted that the obvious way to achieve that does not
work. Although some assumptions will break, for example, there might be
code that assumes that tupleof does the same thing as expand.
I was thinking about e.g., manual cache optimization, but reducing size
in the common case where such considerations are not made may well be
more important. If it can be done at all; I am not currently aware of a
workaround.
