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