Because I'm not satisfied with the current state of memory-layout-flexibility/pureness/safeness/nogc/nothrow-ness of `VariantN` I've hacked together a lightweight version of `VariantN`, I currently call `Cameleon`.

The code is here:

https://github.com/nordlow/justd/blob/master/cameleon.d

Its currently limited to my specific needs (strings and value-types) through

https://github.com/nordlow/justd/blob/master/cameleon.d#L5
https://github.com/nordlow/justd/blob/master/cameleon.d#L35

because it's hard to decrypt the inner `OpID`-workings of `VariantN`.

Questions:

- Is the logic of opAssign and get ok for string?
- How does the inner workings of the GC harmonize with my calls to `memcpy` in `opAssign()` here

https://github.com/nordlow/justd/blob/master/cameleon.d#L80
https://github.com/nordlow/justd/blob/master/cameleon.d#L107

and my zeroing of the internal data buffer in `clear()` here

https://github.com/nordlow/justd/blob/master/cameleon.d#L143

?

- Do I have to call some GC-logic in order to make the GC aware of the new string-reference in `opAssign`?

- Is this logic for `char[]` different from `(immutable char)[]`?
- And what do I need to think about if I allow classes as members?

On Monday, 21 September 2015 at 13:42:14 UTC, Nordlöw wrote:
> Questions:
>
> - Is the logic of opAssign and get ok for string?
> - How does the inner workings of the GC harmonize with my calls to `memcpy` in `opAssign()` here
>
> https://github.com/nordlow/justd/blob/master/cameleon.d#L80

That line won't compile, so don't be afraid of its behavior.

> - Do I have to call some GC-logic in order to make the GC aware of the new string-reference in `opAssign`?

Make sure your struct is always sizeof(void*)-aligned.

On Tuesday, 22 September 2015 at 09:57:58 UTC, Kagamin wrote:
> Make sure your struct is always sizeof(void*)-aligned.

Could that be automatically enforced somehow based on the contents of AllowedTypes?

On Tuesday, 22 September 2015 at 09:57:58 UTC, Kagamin wrote:
>> - Do I have to call some GC-logic in order to make the GC aware of the new string-reference in `opAssign`?
>
> Make sure your struct is always sizeof(void*)-aligned.

How does the GC know if the data block contains a reference (pointer) or value type? Does it try to follow that pointer either way!?

On Tuesday, 22 September 2015 at 12:47:31 UTC, Per Nordlöw wrote:
> How does the GC know if the data block contains a reference (pointer) or value type? Does it try to follow that pointer either way!?

If so when does this memory scanning occurr?

You can generate a union from allowed types, it will make copies type safe too, sort of set!(staticIndexOf(T, AllowedTypes))(rhs)... hmm... can it be an overload?

On Tuesday, 22 September 2015 at 12:54:47 UTC, Kagamin wrote:
> You can generate a union from allowed types, it will make copies type safe too, sort of set!(staticIndexOf(T, AllowedTypes))(rhs)... hmm... can it be an overload?

I believe there is a trait somewhere that figures out the maximum alignment needed for a set/union of types. I think Walter spoke about in a DConf lecture some time ago.

On Monday, 21 September 2015 at 13:42:14 UTC, Nordlöw wrote:
> The code is here:
>
> https://github.com/nordlow/justd/blob/master/cameleon.d

Moved to

https://github.com/nordlow/justd/blob/master/vary.d

Templates are no called:

- FastVariant
- PackedVariant