On Monday, 27 September 2021 at 16:00:01 UTC, Dennis wrote:
> When I try to answer the question, several issues come up.
- I don't understand the concrete problem you're trying to solve. I haven't found the need for head mutable yet so I don't know the challenges that arise when trying to write such a type.
I want to be able to write, in user code, containers that encapsulate arbitrary, ie. including immutable, data types, without necessarily becoming immutable themselves, and without requiring constant allocations. Efficient, safe, low-gc containers for arbitrary data types.
>
- I don't understand the code in your Turducken post because it's too complex to just read and comprehend for me. I need something to look for when analyzing code like that.
The core of it is just
T value;
union { T value; }
struct { union { T value; } }
The ornamental union disables T's destructor, because unions disable destructors: https://github.com/dlang/dmd/pull/5830 This protects us from the destructor ever running for instance during Turducken cleanup, and noticing an invalid value of T
.
The ornamental struct forces a particular codepath in moveEmplace
that uses memcpy in a way that lets us bypass the immutable
fields in T. This is the one thing that I think is kind of a bug. But if we're not escaping value
by ref, it's still safe - because nobody can observe T
's immutable values changing.
>
- The question is addressed to "the language developers", which is a group of people that come and go and submit pull requests to official dlang repos. I can't speak on behalf of everyone and can't promise an indefinite commitment like that.
- What is "value-immutable T" and "correct lifetime accounting"?
immutable int i
= "value immutable" or "head immutable".
immutable(char)[] str;
= "reference immutable" or "tail immutable".
Head/value immutable types cannot be reassigned; their value is immutable. (Tail immutable types can.)
This makes it hard to store value immutable types in a datastructure. For instance, appending to an array of an immutable data type only works because D's runtime magically ignores array immutability for the purposes of appending.
All I'm asking for is the same capability as a user. Preferably without having to resort to GC breaking, unstable hacks like cast(void[]) (&member[0 .. 1])
. (But I will if I have to!)
edit: On consideration, as long as the actual data is just union { T; }
I can probably get away with the void cast and skip the moveEmplace
entirely. That should make my approach less magical, and maybe get it to pass review? I will go try.