Interesting work on packing tuple layout
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Sun Jun 14 23:30:03 UTC 2020
On 6/14/20 3:36 PM, Timon Gehr wrote:
> 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.
It's really easy if members in the layout are given internal names that
include information about the original index.
More information about the Digitalmars-d-announce
mailing list