October 05, 2010
> /*immutable*/ E_MODE[string] a_mode;
> 
> static this () {
>     foreach (m; __traits(allMembers, E_MODE))
>         mixin(`a_mode["` ~ m ~ `"] = E_MODE.` ~ m ~ `;`);
> }

How do you build an immutable AA that is global or local to a function?

Bye,
bearophile
October 06, 2010
On Wed, 06 Oct 2010 03:45:11 +0400, bearophile <bearophileHUGS@lycos.com> wrote:

>> /*immutable*/ E_MODE[string] a_mode;
>>
>> static this () {
>>     foreach (m; __traits(allMembers, E_MODE))
>>         mixin(`a_mode["` ~ m ~ `"] = E_MODE.` ~ m ~ `;`);
>> }
>
> How do you build an immutable AA that is global or local to a function?
>
> Bye,
> bearophile

I found the following to work fine:

K[V] assocArray = createAssocArray();

K[V] createAssocArray()
{
    K[V] assocArray = [
       k1: v1,
       k2: v2,
       ...
    ];

    return assocArray;
}

No idea why the following:

K[V] assocArray = [
   k1: v1,
   k2: v2,
   ...
];

doesn't work directly for global scope.
October 06, 2010
Denis Koroskin:

> I found the following to work fine:
> 
> K[V] assocArray = createAssocArray();
> 
> K[V] createAssocArray()
> {
>      K[V] assocArray = [
>         k1: v1,
>         k2: v2,
>         ...
>      ];
> 
>      return assocArray;
> }

Thank you for your answer. But I need to compute it, so I don't have just an AA literal. And I'd like it to be immutable :-)

Bye,
bearophile
October 06, 2010
On Wed, 06 Oct 2010 04:14:37 +0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Denis Koroskin:
>
>> I found the following to work fine:
>>
>> K[V] assocArray = createAssocArray();
>>
>> K[V] createAssocArray()
>> {
>>      K[V] assocArray = [
>>         k1: v1,
>>         k2: v2,
>>         ...
>>      ];
>>
>>      return assocArray;
>> }
>
> Thank you for your answer. But I need to compute it, so I don't have just an AA literal. And I'd like it to be immutable :-)
>
> Bye,
> bearophile

Compute mutable copy and then cast to immutable. Am I missing something?
October 06, 2010
Denis Koroskin:

> Compute mutable copy and then cast to immutable. Am I missing something?

That's possible. But it's an exceptionally dirty thing, I am not sure it works in SafeD. A well designed const system has to offer a more clean solution :-) Do you agree?

Bye,
bearophile
October 06, 2010
On Wed, 06 Oct 2010 06:02:30 +0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Denis Koroskin:
>
>> Compute mutable copy and then cast to immutable. Am I missing something?
>
> That's possible. But it's an exceptionally dirty thing, I am not sure it works in SafeD. A well designed const system has to offer a more clean solution :-) Do you agree?
>
> Bye,
> bearophile

Yes, that's why I'm interested in exploring deep object cloning solution.
October 06, 2010
On Tue, 05 Oct 2010 22:02:30 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Denis Koroskin:
>
>> Compute mutable copy and then cast to immutable. Am I missing something?
>
> That's possible. But it's an exceptionally dirty thing, I am not sure it works in SafeD. A well designed const system has to offer a more clean solution :-) Do you agree?

Casting to immutable is the only way to create such a beast.  The best way to ensure as few bugs as possible is to create the object you wish to be immutable in a function, and cast at the end before returning.  This at least encapsulates the dirtiness in one function (which would probably be marked @trusted).

You can also use assumeUnique (which I'm guessing is there so it can be called in safeD?).

-Steve
October 06, 2010
Steven Schveighoffer:

> Casting to immutable is the only way to create such a beast.

Then maybe we have to improve the language semantics to allow a better solution. See the Transients of Clojure or the larval objects of Java :-)

The compiler may need to test (at compile time) that there's only one reference to the AA and its contents, and turn it into immutable.

Bye,
bearophile
October 06, 2010
On Wed, 06 Oct 2010 08:12:28 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Steven Schveighoffer:
>
>> Casting to immutable is the only way to create such a beast.
>
> Then maybe we have to improve the language semantics to allow a better solution. See the Transients of Clojure or the larval objects of Java :-)
>
> The compiler may need to test (at compile time) that there's only one reference to the AA and its contents, and turn it into immutable.

Or, we can make array literals (including AA's) immutable, and call it a day.

The only thing is that AA literals provide a nice syntax to make non-immutable AAs also, and I can't think of a good way to make a library function that creates an AA.  Anyone have any ideas?

-Steve
1 2 3
Next ›   Last »